Changelog

KYC profile: pep is replaced by pepDeclaration, and profession is a sector code action required 2026-08-20

Two fields on POST /v1/kyc/data change. Requests keep succeeding either way — no new error is returned — but a value we no longer recognise is not recorded.

• What changes — pep (boolean) is removed. Send pepDeclaration instead, with one of no, yes, family (immediate family member of a politically exposed person) or related (known close associate of one). Omit the field when the holder has not answered; never send no to mean unanswered.
• What changes — profession is now an activity sector code, a short numeric code such as 24. Free text such as "Nurse" is still accepted by the request but is not recorded: it counts as not declared, and the holder is asked to choose a sector while completing verification.
• What to do — if you send pep, switch to pepDeclaration: pep is now ignored, so a declaration sent under the old key is not stored. If you send a free-text profession, either send a sector code or omit the field. Both fields stay optional, and missingFields in the response tells you what is still outstanding.

Orders now return externalReference under the name you send it no action needed 2026-08-18

You set externalReference when creating an order. Until now the order read back carried that value under a misspelled key, externalRefeference, with a doubled e.

• What changes — GET /v1/orders and GET /v1/orders/{orderId} now return externalReference with the value you supplied. Reconciling on the key you wrote with works.
• What does not change — on GET /v1/orders, externalRefeference is still returned with the same value. It is now marked deprecated in the spec and will be removed in a future major version.
• Also — POST /v1/orders now echoes externalReference on the create response, so you can confirm what you sent without a second call. The correct spelling is returned on GET /v1/orders, GET /v1/orders/{orderId}, POST /v1/orders and POST /v1/pending-payments/{transferId}/create-order; the deprecated key was never present on the create or single-order responses and is not being added there.
• What to do — nothing today. When convenient, switch your reads to externalReference; if you branch on the presence of externalRefeference, note that both keys are present.

Corridor discovery returns 503 when a lookup is unavailable action required 2026-08-18

GET /v1/currencies/{currency}/networks and GET /v1/currencies/{currency}/limits now tell an empty answer apart from an answer they could not obtain.

• What changes — when the lookup behind either endpoint is temporarily unavailable, you get 503 with error: "ExternalServiceError". Previously both returned 200 — an empty networks array, or limits: null.
• What does not change — a successful response is identical. An empty array still means the corridor genuinely has no matching networks, and limits: null still means no bounds are published for it.
• What to do — handle 503 on both endpoints by retrying. If you cache either result, only cache a 200: an empty list is settled, a 503 is unknown.

Collections in ARS, COP, CLP, BOB and TWD are no longer available action required 2026-08-07

These five currencies can no longer be used as the origin of a quote or an order — you cannot collect funds in them. Paying out to all five is unchanged and continues to work.

• What changes — POST /v1/quotes and POST /v1/orders reject originCurrency of ARS, COP, CLP, BOB or TWD with a validation error naming the currency.
• What does not change — destinationCurrency still accepts all five. Payouts, destination schemas and existing payout methods are untouched.
• What to do — stop offering these five as collection currencies. Orders already created are unaffected.
• Check availability at runtime — GET /v1/currencies returns what each currency can do today. Read it instead of hardcoding a list, and it will stay correct through later changes.

Chilean peso bank payouts — three fields are now required action required 2026-08-07

A BANK_DEPOSIT_CL destination now takes five fields. Three of them were previously optional and are enforced today — a request that omits any of them is rejected with a validation error.

• Now required — destinationBankName, destinationBankAccountType and destinationTaxId, alongside the destinationName and destinationBankAccount you already send.
• Accepted values — destinationBankAccountType is CORRIENTE or AHORRO. destinationTaxId is the recipient's RUT.
• What to do — add the three fields wherever you build a BANK_DEPOSIT_CL destination, for example on POST /v1/orders and POST /v1/withdrawals.
• Confirm the field list at runtime — GET /v1/currencies/CLP/destination-schema returns the required fields, their formats and their accepted values. Read it instead of hardcoding this list, and it will stay correct through later changes.

Unreleased 2026-08-13

• New: fetch a single conversation — GET /v1/conversations/{conversationId}?endUserEmail= returns one conversation. Previously you had to list an end-user's conversations and pick it out. endUserEmail is required: a conversation is addressed by end-user and id. Additive — nothing you send today changes.
• Unrecognised query parameters are now rejected on the list endpoints — /v1/deposits, /v1/orders, /v1/withdrawals, /v1/pending-payments and their /count variants. A misspelled filter such as ?limitt=5 previously returned 200 with the parameter ignored; it now returns 400. If you send any parameter not listed for the endpoint, remove it.
• city and postalCode are required when paying out to SEPA, ACH_US or GBP_BANK_TRANSFER. Send them in either destinationTransferData or destinationUserData — either location satisfies the requirement. Requests missing both are now rejected at submission with a 400 naming the field, instead of failing later during payout.
• Clearer payout errors. A missing recipient address now returns a message naming the field and where to put it, rather than a generic "user data is not valid".
• New: refundStatus on pending payments. GET /v1/pending-payments and GET /v1/pending-payments/{transferId} may now return refundStatus — one of pending_approval, returning, returned, failed. The field is absent when no refund is in progress. Only returned means the payer has the money back: do not read returning as complete. While the field is present the payment cannot be linked to an order or a deposit, so stop offering it for linking. Additive — nothing you send today changes.

v1.0.0 current 2026-07-06

Initial public API (quotes, orders, deposits, withdrawals, webhooks) on stable JSON contracts — and the launch of this documentation site.