Create a withdrawal
Changed onCreate a PIX withdrawal to transfer BRL funds from your YuvexPay balance. Requires an idempotency key.
The PIX key type (CPF, CNPJ, e-mail, phone, or random key) is detected automatically from destination.pixKey — you do not need to declare it. INVALID_PIX_KEY covers format only. Whether the key exists on the PIX network is not checked before acceptance: depending on when the network rejects, a well-formed key that belongs to nobody surfaces either as a synchronous 400 PROVIDER_ERROR on this call or later as a WITHDRAWAL_FAILED webhook.
The creditor document sent to the PIX network is resolved in three steps, in order: (1) destination.recipientDocument when you send it; (2) the PIX key itself when destination.pixKey is a CPF or CNPJ key; (3) your own verified tax id — company CNPJ for business accounts, owner CPF for individual accounts. Step 3 is a fallback, not a default: if you pay a third party on an e-mail, phone or random key and omit destination.recipientDocument, the network is told your own document is the creditor, and the payout may be rejected downstream by the receiving institution.
Withdrawals may be blocked outside business hours or if your account has restrictions.
creditorDocumentSource is a dashboard-only field and is not accepted here: sending it returns 400 CREDITOR_DOCUMENT_SOURCE_NOT_SUPPORTED rather than being silently ignored. Use destination.recipientDocument to put a specific document on the payout.
Request
- Base URLhttps://api.yuvexpay.com
- AuthHTTP bearer
- TypeScriptA function with typed inputs. Its response is checked against the schema.
Headers
A unique string to ensure the request is processed only once. Must be unique per request. Valid for 24 hours. Successful (2xx) responses are stored and replayed for the key. On POST /v1/payments, a 502 PROVIDER_TEMPORARILY_UNAVAILABLE for a boleto payment is stored and replayed too: to recover that payment, repeat the request once with the same externalId and a new key. A retry of an earlier card payment request now returns 400 CARD_PAYMENTS_NOT_AVAILABLE_VIA_API instead of the stored response (201 or 502): recover that payment with GET /v1/payments/txid/{txId}, or with a create request with the same externalId, mode: "hosted" and methods: ["CARD"], no card object or card fields, and a new key.
Request body
Response
Withdrawal created.
Example response
{
"withdrawal": {
"txId": "WIT1746280868443K3F9Q"
}
}Changes
- breaking
the
response's property type changed fromobjecttostringfor status - warning
removed the optional property
/from the response with the status - warning
removed the optional property
/from the response with the status - warning
removed the optional property
/from the response with the status - info
added the non-success response with the status
- info
added the optional property
to the response with the status - info
added the optional property
to the response with the status - info
added the optional property
to the response with the status
- breaking
- warning
removed the optional property
/from the response with the status - warning
removed the optional property
/from the response with the status - warning
removed the optional property
/from the response with the status - warning
removed the optional property
/from the response with the status - info
added the new optional request property
/ - info
added the non-success response with the status
- warning