📖 Glossary

Definitions for the core terms you'll encounter while integrating the Pix2Depix API.

DePix

A BRL-pegged digital asset issued on the Liquid Network. One DePix tracks one Brazilian Real. The API converts BRL (via Pix) to DePix on a deposit, and DePix back to BRL on a withdrawal.

Liquid Network

A Bitcoin sidechain used to settle DePix on-chain. On-chain settlement references appear in responses and webhooks as blockchainTxID.

Pix

Brazil's instant payment system, operated by the Central Bank. Deposits are funded by a payer scanning a Pix QR code; withdrawals are paid out to a Pix key.

EUID (Eulen User ID)

An end-user identity assigned by Eulen. Pass it as euid to attribute an operation to a specific end user, and query a user's current usage and limits with GET /user-info.

merchantId / EMID (Merchant ID)

A string identifying a merchant (the EMID, or Merchant ID) under your partner account. Pass it as merchantId on POST /deposit to attribute a deposit to a specific merchant.

QR Delay

An optional hold on a deposit, set with delayDepixInHours (1–720) on POST /deposit. A delayed deposit is held until the timestamp returned as delayUntil and reported with status delayed; if omitted, the deposit is processed immediately.

MED (Mecanismo Especial de Devolução)

Pix's special refund mechanism — a chargeback-style reversal that can refund a past deposit to the payer. A reversed deposit moves to status refunded, and a med webhook may be delivered to report it.

MED webhooks

MED is also surfaced as a med webhook event type, registered like any other with /registerwebhook med <url> <secret>. See Webhooks.

X-Nonce (and why there is no idempotency)

X-Nonce is a UUID the server generates for each request and returns in the X-Nonce response header. It is a correlation identifier for tracing and support, not an idempotency key: a nonce sent on the request is not read, and this API has no idempotency mechanism at all. A retried POST /deposit or POST /withdraw can therefore execute twice, so confirm the outcome with the status endpoints before resending.

Response envelope

The uniform JSON wrapper around every API response:

{ "response": { }, "async": false }

Success — { "response": <object>, "async": false }

Error — { "response": { "errorMessage": "<reason>" }, "async": false }, returned with a non-2xx status.

async is always false. There is no asynchronous variant of the envelope, no 202 Accepted, and no urlResponse to poll — that model was removed on 2026-06-12.

The three authentication endpoints do not use this envelope; they answer with { "error": "<code>", "errorMessage": "<text>" }. See Errors.

Client credentials

A client_id / client_secret pair, issued on Telegram with /addclientcredentials. It is not sent on API calls: you exchange it at POST /api/v2/auth/login for an access token (a short-lived JWT, sent as Authorization: Bearer) and a refresh token (an opaque, single-use string that mints the next access token). Each refresh returns a new refresh token and invalidates the one you presented — presenting a used one ends the session. See Authentication.

DePix#

Liquid Network#

Pix#

EUID (Eulen User ID)#

merchantId / EMID (Merchant ID)#

QR Delay#

MED (Mecanismo Especial de Devolução)#

X-Nonce (and why there is no idempotency)#

Response envelope#

Client credentials#

DePix

Liquid Network

Pix

EUID (Eulen User ID)

merchantId / EMID (Merchant ID)

QR Delay

MED (Mecanismo Especial de Devolução)

X-Nonce (and why there is no idempotency)

Response envelope

Client credentials