- By default, the payout is refused with a
429and no money moves. - With queueing on, the payout is accepted and queued. It is sent automatically after 00:00 GMT, when the new day’s limit starts.
Check your limit
GET /v1/transfers/limits
cURL
transfers:read permission.
Limit headers
Live payout responses also carry these headers, so you don’t need a separate call:When the limit is reached
Queueing off
You get a429 with the code DAILY_LIMIT_EXCEEDED. Nothing is taken from your balance. Try again after resets_at.
Queueing on
You get a202 and the payout comes back with the status queued:
- The money is set aside now. The amount and fee leave your payout balance when the payout is queued, so you can’t spend it twice. Only the sending waits.
- First in, first out. Queued payouts are sent oldest first. A new payout joins the back of the line, even if today’s limit has room for it.
- They count against the new day. Payouts sent from the queue use the new day’s limit. If the queue is bigger than one day’s limit, what doesn’t fit waits for the next day.
- They go out shortly after 00:00 GMT. Expect them within a few minutes of midnight. Each one then ends with
transfer.succeededortransfer.failed, like any payout.
429, never queued.
A queued payout can still fail when it’s sent, for example if your daily limit was lowered below its amount. The amount and fee go back to your balance and you get
transfer.failed.Cancel a queued payout
POST /v1/transfers/{id}/cancel
cURL
reason is optional. A restricted key needs the transfers:write permission.
The amount and fee go back to your payout balance, the payout’s status becomes cancelled, and you get a transfer.cancelled webhook. You can also cancel from the payout’s page in the dashboard.
Only queued payouts can be cancelled. If the payout is already being sent, you get a 409.
Webhooks
If you only act on
transfer.succeeded and transfer.failed, queued payouts work with no changes on your side. Treat a 202 as “accepted”, not “sent”.