# Build money movement into your product

Relay gives your backend a focused API for accepting payments, assigning reusable deposit wallets to customers, monitoring organization-owned addresses, and receiving signed lifecycle events.

The API is designed for server-to-server use. Your organization receives an `accesskey` during onboarding; keep it in a secret manager and never expose it in a browser or mobile application.

> **Current production scope:** new payment and wallet work is enabled on TRON and Solana. Always call the active-assets endpoint before presenting a network or token to a customer. Fiat collection currently accepts NGN and settles through the enabled settlement configuration approved for your organization.

## Choose the right collection model

| Model | Best for | Address lifecycle | Start here |
| --- | --- | --- | --- |
| Crypto payment intent | Orders, invoices, or one-off checkouts | A temporary address per intent | [Crypto payment intents](/docs/payments/crypto-payment-intents) |
| Fiat payment intent | NGN bank-transfer checkout | A time-limited virtual account | [Fiat payment intents](/docs/payments/fiat-payment-intents) |
| Customer deposit wallet | Repeated deposits for a known customer | Reused per customer and network | [Customer wallets](/docs/wallets/customer-wallets) |
| External wallet monitoring | Activity on an address your organization already owns | Existing address registered with Relay | [External wallets](/docs/wallets/external-wallets) |

## API conventions

- Production base URL: `https://bridge.relayfinance.io`
- Requests and responses use JSON unless an endpoint says otherwise.
- Authentication uses the `accesskey` request header.
- Successful JSON responses use `success`, `data`, and `meta`.
- Errors use `success`, `error`, and `meta`.
- Every response includes an `X-Request-Id` header. The same value appears in `meta.requestId`.
- Payment and wallet monetary values are decimal **strings**. Do not parse them as JavaScript `number` values. The indicative fiat-rate endpoint is the documented exception.
- Timestamps are ISO 8601 strings in UTC.

```json
{
  "success": true,
  "data": {
    "txId": "RLY-01J9Y7Y9F4M6",
    "status": "pending"
  },
  "meta": {
    "requestId": "7ed44f9c-e1ea-4f60-a78f-bf97074dc3ca"
  }
}
```

## A typical integration

1. Complete Relay onboarding and configure approved settlement destinations in the dashboard.
2. Store your organization API key on your server.
3. Query active payment assets, then create a payment intent or customer wallet.
4. Show the returned deposit instructions to your customer.
5. Receive and verify signed webhooks, deduplicating by event ID.
6. Retrieve the resource when you need the latest authoritative state.

Funding and settlement are separate stages. A funded event confirms eligible incoming funds; it does not by itself prove that the outgoing settlement reached its destination. Read `settlementStatus` and the later settlement events independently.

## Documentation formats

Every page is available as Markdown through its **View Markdown** action. The complete documentation corpus is also available at [`/docs/llms.txt`](/docs/llms.txt) for development tools and language models.

Ready to make a request? Continue to the [quickstart](/docs/getting-started/quickstart).