> ## Documentation Index
> Fetch the complete documentation index at: https://rain-sandbox-trial.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.
# Partner-Managed Limits
> How Rain allows partners to set up limits for onramp and offramp volume through payment routes and transfers, what you see when a deposit exceeds a limit, and how to read a user's remaining limit.
Use this page to understand the limits you can set on your users' onramp and offramp activity, and to build your integration so users are never surprised by a returned deposit. Limits can apply to every onramp and offramp, whether the funds move through a [payment route](/docs/onramps) or through the quote and [transfer](/docs/transfers) flow.
Limits are configured per program at your request. The limits endpoint (`GET /v1/limits`) is enabled per tenant. Contact your Rain account manager to enable the endpoint and to set or change limits.
## How you set limits
You set limits for your program by asking Rain. Message your Rain account manager with the limits you need.
Each limit combines the following dimensions:
| Dimension | Options |
| - | - |
| Direction | Onramp or offramp. Reported as `limitType` `onramp_usage` or `offramp_usage`. |
| Interval | Daily or per transaction. A daily limit accumulates deposits against the ceiling, and the window resets at midnight in a fixed UTC-5 zone with no daylight-saving adjustment, so every day at 05:00 UTC. A per-transaction limit caps each deposit on its own and keeps no running usage. |
Each limit applies to one account. For consumer accounts that is the individual user. For corporate accounts it is the company, so all of its users share one limit. You can set a default for every account and override it for individual accounts.
Limits are always denominated in USD. Other currencies are counted after conversion to USD using the exchange rate applied to the transfer: the rate on the quote for quote-based transfers, or the rate on the transfer for payment-route deposits. The converted amount is rounded up to the cent.
## Where a limit shows up in the API
Payment-route deposits are checked when the funds arrive, because the amount is unknown until then. Transfers are checked when you create them, because the quote fixes the amount.
| Endpoint | Checked against limits? | What you see |
| - | - | - |
| `POST /v1/payment-routes` | No | Route is created as normal. Every deposit into it is checked when it arrives, as described below. |
| `POST /v1/quotes` | No | Quote is created as normal. |
| `POST /v1/transfers` | Yes | A transfer over the limit is rejected with `400 Bad Request`. The message states the remaining allowance. |
| `GET /v1/limits` | Read only | The user's limits with current usage, so you can warn before the deposit is sent. |
### A transfer that exceeds a limit
1. `POST /v1/quotes` succeeds. Quotes are not checked against limits.
2. `POST /v1/transfers` is rejected with `400 Bad Request`. The message states the remaining allowance. No transfer is created and nothing is counted against usage.
A transfer that is created has passed the check and is not checked again when the deposit arrives, so a transfer in `pending` or `awaiting_transfer` will not be refunded for a limit.
### A payment-route deposit that exceeds a limit
A payment-route deposit is checked after its transfer transaction is created, so a transfer in `pending` or `processing` can still be refunded for a limit.
1. The transfer transaction is created (`transactionTransfer.created`).
2. Rain returns the funds. While the return is in progress the transfer shows `pending_review` or `processing`. Fiat onramp deposits go back to the originating bank account, and stablecoin deposits go to the payment route's `refundAddress`.
3. The transfer moves to `refunded`. You receive a `transactionTransfer.updated` webhook, and `GET /v1/issuing/transactions` returns the same status.
A transfer can also show `pending_review` while Rain holds it for a compliance review. Treat `pending_review` as in progress, not as a failure: the transfer returns to `processing` when released, or moves to `refunded` if Rain returns the funds.
## Read a user's remaining limit
Call `GET /v1/limits?userId=` to show a user how much they can still move today. Each returned limit carries the ceiling (`amount`) and its `interval`. A daily limit also carries what has been used in the current window (`used`) and when the window resets (`windowResetAt`). A per-transaction limit omits those fields because it keeps no running usage. Amounts are decimal strings in the currency's major units. Windows reset at midnight in a fixed UTC-5 zone with no daylight-saving adjustment, so `windowResetAt` is always 05:00 UTC.
```json Response theme={null}
{
"limits": [
{
"limitType": "onramp_usage",
"currency": "usd",
"amount": "10000.00",
"used": "7500.00",
"interval": "daily",
"windowStart": "2026-07-04T05:00:00Z",
"windowResetAt": "2026-07-05T05:00:00Z"
},
{
"limitType": "onramp_usage",
"currency": "usd",
"amount": "2500.00",
"interval": "per_transaction"
}
]
}
```
An empty `limits` array means no daily or per-transaction limit is configured for the user. Rain's compliance and risk controls still apply to every deposit.
## Best practices
1. **Warn before the deposit is sent.** Call `GET /v1/limits` when you display deposit instructions and check every limit whose `limitType` matches the direction: compare the deposit's approximate USD value with `amount` minus `used` for a daily limit, or with `amount` for a per-transaction limit. Show the user `windowResetAt` if they need to wait.
2. **Explain refunds.** When a transfer reaches `refunded`, tell the user the funds are on their way back and when they can try again.
3. **Make sure the `refundAddress` on every offramp payment route** is a wallet your user can access, so a returned stablecoin deposit lands somewhere they can reach.
## What's next
Payload fields and status values for `transactionTransfer` events.
Create payment routes for fiat deposits.