Base URL#
One environment. Test against the Sandbox connectors rather than a separate host.
Requests#
REST over JSON. Send Content-Type: application/json on every request with a body, and the credential in X-API-KEY — see AuthenticationAPI. Verbs mean what they say: GET reads, POST creates, PATCH updates, DELETE removes.
Responses#
JSON. The API evolves without versions by adding fields to responses; nothing is removed or renamed. Your client has to accept and ignore fields it does not know — most HTTP libraries do by default, a strict deserializer may not.
Errors share one shape, whatever the endpoint:
code repeats the HTTP status; codeDescription, when present, is the stable identifier to branch on; message is for people. Some errors add a data object. The status codes are listed in Error CodesAPI.
Pagination#
Two models are in use. The v2 endpoints paginate with a cursor; every other list endpoint still paginates by page number.
Cursors are how this API paginates from here on, and page-number pagination is being phased out. Where a v2 cursor endpoint exists, write your integration against it.
Cursor (v2 endpoints)#
Ask for the first page with your filters. The response carries the records and next: a ready-made query string for the following page.
| Field | Meaning |
|---|---|
results | The records of this page. |
next | The query string of the next page, or null on the last one. |
To continue, append next to the endpoint path exactly as received — it already carries your filters and the after cursor:
Never build or decode after yourself: the value is opaque and only valid as returned. A null next means there is nothing more to read. Cursor pagination is available on GET /v2/transactionsAPI and GET /v2/itemsAPI — the latter is opt-in per team; ask support to enable it.
Page number (other list endpoints)#
Investments, investment transactions, credit card bills (GET /bills), payment customers, recipients and requests, and Smart Transfer pre-authorizations paginate by page:
| Field | Meaning |
|---|---|
total | Records matching the request, across all pages. |
totalPages | Pages needed to read them all. |
page | The page in this response. |
results | The records of this page. |
Two query parameters drive it: page (default 1) and pageSize (default 500 where the endpoint accepts it — check the endpoint). To read everything, request page=1, then page=2 … up to totalPages.
Every list endpoint outside v2 paginates this way today, and these are expected to gain cursor equivalents. Keep the paging logic in one place in your integration: moving an endpoint across is then a change in one function rather than at every call site.
GET /transactions is deprecated
The page-based GET /transactionsAPI is deprecated and available only until 2026-12-31, as announced in the changelog since June 2026. Move to GET /v2/transactionsAPI, which paginates by cursor as above.
Applications created on or after 2026-06-02 00:00 Brasília time (03:00 UTC) already get 410 Gone with codeDescription ENDPOINT_DEPRECATED from GET /transactions, and must use /v2 from the start.
Moving from GET /transactions to GET /v2/transactions#
GET /transactions | GET /v2/transactions |
|---|---|
accountId | accountId (same) |
ids | ids, comma-separated, up to 500 (same) |
from / to | dateFrom / dateTo |
createdAtFrom | createdAtFrom (same; cannot be combined with dateFrom) |
page / pageSize | after: follow the next value of each response until it is null. Pages hold up to 500 transactions. |
billId, type, operationType | Not available as filters. Every transaction still carries these fields (billId inside creditCardMetadata), so filter on your side. |
transactions/created webhook: createdTransactionsLink | Applications created before 2026-06-02 00:00 Brasília time (03:00 UTC): use createdTransactionsLinkV2 from the same payload. |
Read the guide: Basic concepts.