Skip to content

Price and send in one call.

POST

Path parameters

  • orgIdstringRequired

    The opaque organization id issued to you, normally CUID-shaped (for example cmsx…). It is not an org_-prefixed alias. Pass it unchanged in every organization-scoped path.

Headers

  • Idempotency-KeystringRequired

    A unique value per logical operation, 1-255 chars of A-Z a-z 0-9 _ . : -.

    More

    Reuse it to retry. Same key with the same body replays the stored response; same key with a different body is a 409, because answering with the first call's result would hand you a receipt for a payout you did not request. A 4xx releases the key, so you can fix the body and reuse it.

    Reuse it; do not generate one per attempt. A key minted per attempt defeats replay entirely: every retry looks like a new request, so every retry pays. We also watch for an identical body arriving under a different key within 15 minutes and refuse it with DUPLICATE_REQUEST_DETECTED.

    Records are kept for 7 days. That is a retention window only: there is no path where an expired key is re-executed.

  • X-Allow-DuplicatestringOptional

    Set to true to send a request that is byte-identical to one you sent within the last 15 minutes under a different key. true is the only accepted value. It switches off the guard that catches a retry arriving under a fresh key, so send it only when you mean to pay twice.

Body

This endpoint expects a JSON object.

  • amountstringRequired

    How much, as a decimal string. What you send by default; what the recipient receives, in their currency, when amountLeg is destination.

  • destinationAccountIdstringRequired

    The recipient's method.destinationAccountId from the registration response (the account that call registered), or the one you stored for it.

  • amountLegstringOptionalDefaults to "source"

    Which side of the payout amount describes.

    More

    source takes every fee out of what you sent, so the recipient receives less than the figure you named.

    destination pays them that figure exactly, in their currency, and adds the fees to your debit instead. Naming 3400 MXN on a live corridor debited 201.879397 USDC and paid out 3400.00.

    source_net keeps the figure in your currency but means it the same way: "send them $200 worth". We convert at the market rate published by GET /rates and lock that destination, so the fees land on your debit. Naming 200 USD on a live corridor paid out 3426.81 MXN and debited 203.447236: the fees, plus the difference between the market rate we quoted you and the rate the network executed at.

    The two locking modes need capabilities.exactOutput on the corridors call; elsewhere they are refused with EXACT_OUTPUT_UNSUPPORTED rather than quietly pricing the other side.

    Allowed values:sourcedestinationsource_net
  • expectDestinationstringOptional

    What you told the payer they would receive. Omit it and you send at whatever the market did between quoting and sending.

  • maxDriftBpsintegerOptionalDefaults to 200

    Tolerated drift in basis points. Defaults to 200 (2%). Only read when expectDestination is set; ignored otherwise.

  • referencestringOptional

    Your payment reference. Echoed back and searchable.

  • purposeOfPaymentstringOptional

    Corridor-defined payment purpose, from GET /payment-reasons. Required for payouts to INR, GHS, CNY and BRL; validated against the catalog whenever you send it; never defaulted.

  • endUserobjectOptional

    Your own customer this payout is sent for: the party sending through your platform, never the recipient. In payroll the employer is the end user and the worker is the recipient; omit the object when you are the sender yourself. Attribution and the per-end-user daily cap key on id; it is not forwarded to the payment network and does not change the sender of record, which stays your organization. Echoed on the payout and in every webhook, so a support question is answerable without your own id map.

    Show 3 properties
    • idstringOptional

      Your stable identifier for the sending customer (not the recipient).

    • namestringOptional

      Person's display or legal name.

    • emailstring<email>Optional

      Person's email address in standard email format.

Behavior

Build on this endpoint. It prices and sends in a single request, which is what makes a retry safe: the body you send is the body you can send again. Pricing separately and then sending means a retry re-prices, produces a different request, and the Idempotency-Key meant to protect the retry conflicts with itself instead.

Pass expectDestination, the amount you told the payer they would receive. If the binding quote has moved further than maxDriftBps from it, we refuse and nothing is sent.

If this times out the outcome is unknown and the payout may exist. Retry with the same Idempotency-Key. A 500 PAYOUT_OUTCOME_UNKNOWN means the same thing: never retry it under a new key. Look for the payout with GET /orders?reference=<your reference> first.

202 instead of 200. When your organization requires approval on API payouts and this one is above the threshold, nothing is priced or sent: you get { status: "pending_approval", approvalId, … }. Watch GET /payouts/approvals/{approvalId} or the payout_approval.* events; payout_approval.executed names the payoutId it became. Your approvers act in the dashboard; a key cannot approve.

Responses

200The payout. A replayed idempotent request returns the original and sets the Idempotency-Replayed response header.

Headers

  • Idempotency-Replayedboolean

Body · Payout

  • payoutIdstringOptional
  • statusstringOptional

    A payout moves only along these transitions:

    More
    pending    -> processing | completed | failed | canceled
    processing -> completed | failed
    completed  -> failed                  (returned by the recipient's bank)
    
    • pending: accepted, reserved, not sent. The only cancelable state.
    • processing: handed to the payment network. Committed.
    • completed: the recipient was paid. Not absolutely final.
    • failed: not paid, or paid and then returned. Branch on failureCode.
    • canceled: you ended it before it was sent. It is not a failure, so it carries no failureCode; fundsReturned is true because the money never left.

    completed can still become failed. A receiving bank can return a payment days after settlement, giving failureCode: returned_by_bank and fundsReturned: true. Do not write a ledger that treats completed as immutable, and keep processing webhooks for a payout after it completes.

    Allowed values:pendingprocessingcompletedfailed
    Show 1 more valuecanceled
  • stagestringOptional

    Informational sub-state on a slow payout, so your support team can answer "where is it?". Non-authoritative: never branch integration behavior on it, and treat an unrecognized value as the status alone.

    Allowed values:awaiting_detailsunder_reviewsettling
  • failureCodestringOptional

    New codes may be added; treat an unknown one as execution_failed.

    Allowed values:quote_expiredinsufficient_fundslimit_exceededaccount_invalid
    Show 6 more valuesaccount_cannot_receivecompliance_rejectedauthorization_not_completedreturned_by_bankexecution_failedunknown
  • requiresFundingbooleanOptional

    Present and true when this payout is waiting on you to fund it from your own wallet. Absent on routings that settle on acceptance, so its presence is the signal.

  • fundsReturnedbooleanOptional

    Whether the money is back in your balance. Separate from failureCode, because the same cause can go either way depending on how far the payment got.

  • sourceAmountobject | nullOptional

    Always a decimal string, never a float and never base units. Floats lose cents at scale; base units mean every integrator re-derives the exponent.

    Show 2 properties
    • currencystringRequired
    • amountstringRequired
  • destinationAmountobject | nullOptional

    Always a decimal string, never a float and never base units. Floats lose cents at scale; base units mean every integrator re-derives the exponent.

    Show 2 properties
    • currencystringRequired
    • amountstringRequired
  • destinationAccountIdstring | nullOptional
  • feeobject | nullOptional

    The fee, already inside sourceAmount, deducted from the send not added on top, so destinationAmount = sourceAmount x rate still holds. The same value the event data and the payout row on /balance_transactions report. Null when the rail has not disclosed it, which is "not known", not zero.

    Show 2 properties
    • currencystringRequired
    • amountstringRequired
  • ratestring | nullOptional

    The effective rate: destinationAmount / sourceAmount, derived from this payout's own amounts with the fee inside, so destinationAmount = sourceAmount x rate always holds. Lower than the indicative mid-rate GET /rates showed for the same conversion by exactly the fee share; that is not the rate moving. Compare it to PreviewQuote.rate only after netting the fee. Always six decimal places, rounded half-up ("16.923250"). Null until the amounts are known.

  • referencestring | nullOptional
  • endUserobject | nullOptional

    Your own customer this payout is sent for: the party sending through your platform, never the recipient. In payroll the employer is the end user and the worker is the recipient; omit the object when you are the sender yourself. Attribution and the per-end-user daily cap key on id; it is not forwarded to the payment network and does not change the sender of record, which stays your organization. Echoed on the payout and in every webhook, so a support question is answerable without your own id map.

    Show 3 properties
    • idstringOptional

      Your stable identifier for the sending customer (not the recipient).

    • namestringOptional

      Person's display or legal name.

    • emailstring<email>Optional

      Person's email address in standard email format.

  • createdAtstring<date-time> | nullOptional
  • updatedAtstring<date-time> | nullOptional

    When this payout last changed. Carry the highest value you have seen as your updatedSince watermark. Without it in the payload the change feed cannot be paged.

  • completedAtstring<date-time> | nullOptional
  • expectedSettlementAtstring<date-time>Optional

    When the funds are expected to be available to the recipient, where the routing states a settlement timeline. Present only when known; an estimate, not a promise.

202Held for your approvers. Nothing was priced or sent. Idempotent: a replay of the same key returns the same approval.

Body · PendingApproval

  • statusstringRequired
  • approvalIdstringRequired

    Read it at GET /payouts/approvals/{approvalId}; payout_approval.executed names the payout.

  • approvalRequestIdstringOptional

    Same value as approvalId; kept for the dashboard client.

  • requiredApprovalsintegerRequired
  • expiresAtstring<date-time>Required

Errors

  • 400

    Nothing was sent on any of these.

    • VALIDATION_ERROR: a field is malformed; errors names it.
    • INSUFFICIENT_BALANCE: your balance does not cover the payout.
    • RATE_DRIFT_EXCEEDED, QUOTE_UNVERIFIABLE: the drift guard refused. Re-quote and send again.
    • QUOTE_NOT_POSITIVE: fees would leave the recipient with zero or less. Increase the amount first.
    • EXACT_OUTPUT_UNSUPPORTED: amountLeg: destination or source_net on a routing without capabilities.exactOutput.
    • INDICATIVE_PRICING_UNAVAILABLE: amountLeg: source_net on a routing that publishes no market rate.
    • DESTINATION_ACCOUNT_NOT_FOUND (as a 400): amountLeg: source_net for a recipient with no payout currency on file. An unknown destinationAccountId is a 404.
    • BAD_REQUEST: the network refused the quote (for example it expired) or the amount is outside the corridor's range; detail says which.
    • IDEMPOTENCY_KEY_REQUIRED, IDEMPOTENCY_KEY_INVALID: the header is missing or malformed.
  • 401

    The key was refused. Nothing ran.

    • UNAUTHORIZED: missing, invalid or revoked, or a key on a route that does not accept one.
    • KEY_EXPIRED: the key passed the expiry it was issued with. Issue a new one; an expired key cannot be rotated.
    • KEY_IP_NOT_ALLOWED: the key is pinned to source addresses and this request came from another.
  • 403

    A valid key that may not make this write. Nothing was changed.

    • FORBIDDEN: the key belongs to a different organization.
    • ACCOUNT_BLOCKED: API access for your organization is suspended.
    • LIVE_KEY_ORG_NOT_APPROVED: a live key, before we have approved your business verification. Use a test key until then.
    • INSUFFICIENT_SCOPE: a read-only key. Issue one with the write scope.
  • 404

    DESTINATION_ACCOUNT_NOT_FOUND: no payment method with this destinationAccountId belongs to your organization. Nothing was sent. Use a destinationAccountId from a recipient you created.

  • 409

    On a route that moves money:

    • IDEMPOTENCY_KEY_CONFLICT: the key was reused with a different body. Use a new key for a new request.
    • IDEMPOTENCY_KEY_REQUEST_IN_PROGRESS: the first request with this key is still running. Back off and retry the same key.
    • PAYOUT_OUTCOME_UNKNOWN: a replay of a key whose first call answered 500 PAYOUT_OUTCOME_UNKNOWN. Money may have moved. Do not send a new key; look the outcome up first. originalRequestId names the first call.
    • DUPLICATE_REQUEST_DETECTED: an identical body under a different key within 15 minutes. Nothing was executed. Retry with originalIdempotencyKey, or send X-Allow-Duplicate: true if you mean to pay twice.
  • 422

    A control refused it and nothing was sent. PAYOUT_LIMIT_EXCEEDED: over a single, daily, or per-end-user daily cap. The message names which; split it or ask us to raise the cap. PAYOUT_REFUSED: this payout cannot be sent to this recipient; do not retry, contact us with the requestId.

  • 429

    Too many requests. The default ceiling is 100 requests per minute per API credential on a 60-second window. High-volume payout and reconciliation routes declare a 600/minute override, and batch submission a 30/minute ceiling. A separate 2,000/minute per-source-IP abuse ceiling always applies.

    Obey Retry-After; it is in seconds and is authoritative. A 429 means the request was refused before the handler ran. Retry reads normally; retry an idempotent mutation with its same Idempotency-Key.

  • 500

    PAYOUT_OUTCOME_UNKNOWN: the call failed after the money may have moved, and we cannot yet say whether it did. Do not retry with a new Idempotency-Key; that is how a payment goes out twice. Look the outcome up first (the operation says where), or replay the same key, which answers 409 PAYOUT_OUTCOME_UNKNOWN until we resolve it. Send support the requestId.

    Every other 500 is INTERNAL: nothing was recorded under the key, and retrying with the same key is safe.

Error body · Error
  • typestringRequired

    Stable machine-readable code.

  • detailstringRequired

    What went wrong, in a sentence. Always a string, so detail.toLowerCase() is safe.

    More

    This is the field to read on BAD_REQUEST and PROVIDER_REJECTED, where the type alone does not name the condition.

  • messagestringRequired

    The same text as detail, kept for integrations written before detail existed. Read detail.

  • resolutionstringOptional

    What to do about it, when there is a specific answer. It is not on every error (it is absent on BAD_REQUEST, NOT_FOUND, PAYOUT_NOT_CANCELABLE and DESTINATION_ACCOUNT_NOT_FOUND), so treat it as optional and fall back to detail.

  • statusintegerRequired

    HTTP status, repeated in the body.

  • statusCodeintegerRequired

    The same value as status, kept for integrations written before status existed. Read status.

  • requestIdstringRequired

    Quote this to support and we can find the exact request. Also sent as the x-request-id response header, which is the only place it appears on a successful response. Success bodies do not carry it. Send your own x-request-id on the request and we use it, so your trace and ours share one identifier; otherwise we mint one.

  • errorsarray of stringOptional

    Present on VALIDATION_ERROR; names each field that failed.

  • originalIdempotencyKeystringOptional

    On DUPLICATE_REQUEST_DETECTED only. Send the request again with this to receive the original payout instead of making a second one. Without it there is no way to recover except by risking a double payment.

  • originalPayoutIdstringOptional

    On DUPLICATE_REQUEST_DETECTED only. The payout the first request created.

  • originalBatchIdstringOptional

    On a batch DUPLICATE_REQUEST_DETECTED. The run the first request created.

  • originalRequestIdstringOptional

    On a 409 PAYOUT_OUTCOME_UNKNOWN replay. The requestId of the call whose outcome is unknown; quote it to support.

  • existingRecipientIdstringOptional

    On BANK_ACCOUNT_ALREADY_LINKED. The recipient in your organization that already holds this account.

  • existingMethodIdstringOptional

    On BANK_ACCOUNT_ALREADY_LINKED. The payment method on that recipient.

Branch on type, never on the status or the message. Every error type is listed with what to do about it.

Avvio Partner Payouts · Payouts · operation createPayout

Try it: Create a payout

POST https://api.avvio.xyz/business/api/v1/payments/organizations/{orgId}/payouts

Test keys only. Sent as x-api-key through this site's proxy to the Avvio API, never saved, and cleared when you close this dialog.

Was this page helpful?