Transactions Endpoint Factsheet
This factsheet should provide additional information for handling and understanding the GET /accounts/{accountId}/transactions endpoint in the Account API.
The API returns a single AccountTransactionReport object containing:
- A list of transaction entries and their transaction details
- Account identifiers
- Optional links to related account or balance resources
The endpoint supports both finalized and intraday use cases, depending on the query parameters provided.
The dateFrom and dateTo parameters control the date range for returned transaction data according to the bookingDate of the entries.
| Use Case | dateFrom | dateTo | Response | Description |
|---|---|---|---|---|
| Intraday activity | (empty) | (empty) | 200 | Returns transactions since the last completed booking day, including weekends or holidays. May include pending entries. |
| Today's date only | Today | Today | 202 | Booking day not finalized yet. No data returned. Retry later. |
| Past to today | Past date | Today | 200 | Returns finalized transactions up to the last completed booking day. Today’s data is excluded if not yet finalized. |
| Historical range | Past date | Past date | 200 | Returns transactions from finalized booking days within the range. |
| No available data | Invalid or purged date range | Any | 204 | No data available and none will be provided for this range. |
Note: Most banks do not finalize booking days on weekends or public holidays.
These dates are technically treated as non-booking days and will be completed on the next regular working day.
The endpoint supports cursor-based pagination to handle large result sets efficiently.
Entries must be returned in a stable and deterministic order, both across and within pages. The primary sorting criterion must be bookingDate in descending order. Additional sorting logic is provider-specific, but must ensure consistency and reliability for pagination.
Pagination is controlled using an opaque cursor returned in the X-Next-Cursor response header. The cursor identifies a specific position in the sorted result set and is derived from internal sorting keys. Its format is internal to the provider and may vary. Clients must not interpret, generate, or modify the cursor, and must pass it unchanged in the cursor parameter of the next request.
Cursors remain valid long enough for clients to retrieve a full transaction history or current-day data across multiple paginated requests, even while new transactions are being booked. However, cursors may expire after a defined period of inactivity (e.g., 30 minutes) or due to system changes. If a cursor is no longer valid, clients must restart pagination by omitting the cursor parameter.
-
limit(optional): Maximum number of entries to return. The provider must not return more than the specified limit, but may return fewer. The actual number of items returned can vary between pages. -
cursor(optional): Opaque token returned by the server to continue pagination.
-
X-Next-Cursor: If present, more results are available. Pass its value unchanged in the next request’scursorparameter.
If not present, the full result set has been returned.