1. 🧩 Advanced (optional)
Pix2DePix API
  • 📜 API Overview
  • Docs
    • 🔑 Authentication
    • 💻 Examples
    • 🪝 Webhook
    • ✅ Possible Statuses
      • 📥💰 Deposit Statuses
      • 📤💸 Withdraw Statuses
    • 🛡️ Security & Limits
      • ✅ Best Practices
      • 🪲 Bug Bounty
      • 🧱 Firewall
      • 🚦 API Limits
    • 🧩 Advanced (optional)
      • 🎲 Nonce
      • 🔀 Synchronous requests & safe retries
    • 🚀 Features
      • ⏱️ QR Delay
  • API Endpoints
    • Ping
      GET
    • Deposit (PIX ➔ DePix)
      POST
    • Deposit Status
      GET
    • Deposits
      GET
    • User Info
      GET
    • Withdraw
      POST
    • Withdraw Status
      GET
  • Webhooks
    • Deposit Webhook
    • Withdraw Webhook
    • MED Webhook
  • Schemas
    • AllPossibleObjResponses
    • StandardResponse
    • PingObjOrError
    • JWTClaims
    • ObjResponse
    • ErrorObj
    • PingObj
    • ErrorResponse
    • DepositRequest
    • DepositObjOrError
    • DepositObj
    • PingResponse
    • DepositResponse
    • DepositStatusObj
    • DepositStatusResponse
    • DepositWebhookBody
    • DepositsResponse
    • DepositStatus
    • UserInfoResponse
    • WithdrawStatusResponse
    • WithdrawStatusObj
    • WithdrawResponse
    • WithdrawObj
    • WithdrawStatus
    • WithdrawWebhookBody
    • MEDWebhookBody
    • RejectionReasons
  1. 🧩 Advanced (optional)

🔀 Synchronous requests & safe retries

The API is synchronous: every call holds the connection open and returns its final result inline, in the standard envelope. There is no asynchronous mode and no result to poll. It also has no idempotency mechanism, which changes how you must handle a failed POST /deposit or POST /withdraw — that is the second half of this page, and it is the part worth reading twice.

The API is synchronous#

Every response comes back inline, in the standard envelope, with async always false:
{
  "response": { "...": "..." },
  "async": false
}
There is no 202 Accepted, no urlResponse, and nothing to poll. If an operation takes too long, the connection times out and you receive 503. On a call that moves money, that timeout tells you nothing about whether the operation was created — check its status before deciding what to do (see Retrying safely).

X-Async is no longer supported#

X-Async was part of an earlier asynchronous model that has been removed. Sending X-Async: true (or X-Async: 1) is now rejected up front, before any work is done, with HTTP 400:
{
  "response": { "errorMessage": "X-Async: true is no longer supported" },
  "async": false
}
Any other value (false, auto, or omitting the header entirely) is accepted and served synchronously, so the simplest integration just leaves the header off.
Remove X-Async from your requests
If you previously sent X-Async: true to defer work, stop — that request now fails with 400. Drop the header and read the result inline. There is no polling URL to migrate to.

X-Nonce is a tracing header, not an idempotency key#

The API has no idempotency mechanism
X-Nonce is generated by the server, one per request, and returned to you in the response header. A nonce you set on the request is not read and deduplicates nothing. There is no idempotency key, and no other mechanism that makes a repeated POST /deposit or POST /withdraw resolve to the original operation.
If you retry a value-moving call, you can execute it twice.
Use the nonce for what it is: a correlation identifier. Log it and quote it in support requests.

Response headers#

Every response carries correlation headers:
HeaderMeaning
X-NonceThe identifier the server generated for this request. Not an input, and not an idempotency key.
X-Request-IDA unique UUID for this individual request. Include it when contacting support.

Retrying safely#

Because nothing deduplicates for you, the safe pattern is to establish the outcome before resending.
Read-only calls (GET /ping, /deposit-status, /withdraw-status, /deposits, /user-info) are safe to retry freely.
POST /deposit and POST /withdraw are not. After a timeout, a 5xx, or a dropped connection, do not resend blindly. Confirm the outcome first:
1.
Query GET /deposit-status or GET /withdraw-status, or wait for the webhook.
2.
Resend only after confirming the operation was never created.
Definitive refusals are not retryable at all. A 520 (business rejection) and a 422 (compliance block) will return the same answer every time.
Turn off automatic retry on the two write endpoints
Most HTTP libraries retry 5xx by default, and the rejection code 520 sits inside that range — so a business refusal can be retried by your client library without you writing a single line of retry code. On POST /deposit and POST /withdraw, disable automatic retries and handle the outcome explicitly.

Correlating a call you are unsure about#

Log the X-Nonce and X-Request-ID from every response. When an operation's outcome is unclear and the status endpoints do not settle it, those two values are what support needs to trace the call.
-i prints the response headers, where both identifiers arrive:
Modified at 2026-08-11 06:02:09
Previous
🎲 Nonce
Next
⏱️ QR Delay
Built with