Partner-wide transactions

GET /api/partner/transactions returns every transaction the calling partner is allowed to see, aggregated across all of their linked accounts.

The full request/response contract lives on the API reference page →. This page describes what the partner passes, what they see in the response, and how edge cases are reported.

Pagination contract

GET /api/partner/transactions is paginated.

• Default: page=1
• Default: limit=10
• Example: GET /api/partner/transactions?page=1&limit=3000
• There is currently no enforced maximum limit value in the Partner API implementation.
• If the caller omits limit, the backend uses 10.

The same applies to the per-individual transaction endpoint: GET /api/partner/individual/accounts/{id}/transactions defaults to page=1 and limit=10.

What you pass

The endpoint accepts the standard page and limit pagination parameters and an optional date range (dateStart, dateEnd). Two further filters are available but they are mutually exclusive — pass one or the other, never both.

?accountIdentification=… — narrow to one or more IBANs

One IBAN, a comma-separated list, or repeated query keys — all of these are accepted and behave the same:

Request shape	Example
Single value	?accountIdentification=DE89370400440532013000
Comma-separated	?accountIdentification=DE1,DE2
Repeated keys	?accountIdentification=DE1&accountIdentification=DE2

Only IBANs the partner owns are forwarded to the upstream transaction history. An IBAN the partner supplied that does not belong to them is simply ignored. If the request included IBANs and none of them belong to the partner, the endpoint returns 404 IBAN not found..

?cardId=<cardKey> — narrow to a single card

Pass exactly one cardKey to fetch the transactions for that card. Multiple values (repeated query keys or a comma-separated list) is a request-shape error and returns 400 Pass exactly one cardId — multiple distinct cardKeys are not allowed.. When the cardId filter is used, the partner's accountIdentification is not required — a cardKey alone is enough.

A cardKey that does not belong to the partner returns 404 Card not found!.

What you see

Filter combination	Response
No filters	Transactions across every IBAN the partner owns.
?accountIdentification=DE1,DE2	Transactions restricted to the supplied IBANs (filtered to the partner's owned ones).
?cardId=<cardKey>	Transactions for that single card.
Both filters at once	400 Pass either accountIdentification OR cardId, not both.

The response shape is the same TransactionListResponse used by the per-individual endpoint:

{
  "data": [/* transactions */],
  "pagination": {
    "total": 33452,
    "page": 1,
    "limit": 10,
    "totalPages": 3346
  }
}

Not-found responses

Both filter paths share the same convention: if the supplied value isn't something the partner owns, the endpoint returns 404 with a flat "not found" body.

Filter	Not-found response body
accountIdentification	IBAN not found.
cardId	Card not found!

The wording is intentionally flat — it doesn't distinguish between "this resource doesn't exist" and "this resource exists but belongs to a different partner". Use GET /me if you need to confirm which IBANs and cardKeys the partner owns before querying.

Edge cases

• No IBANs at all — if the partner has no IBANs linked yet, the endpoint returns 400 No IBANs found for the linked individual accounts. rather than calling the upstream with an empty filter.
• No transactions in the date/page range — the upstream's "no transactions found" is mapped to HTTP 200 with data: [], same as the per-individual endpoint.
• Mutually exclusive filters — passing both at once returns 400 with no upstream call.

Per-individual transactions

If the caller knows the specific onboarding, the narrower GET /individual/accounts/{id}/transactions endpoint also exists. The partner-wide endpoint is the right choice when the caller doesn't know which onboarding owns the IBAN, or wants a single combined view across the partner's full portfolio.

Per-B2B-tenant transactions

If the caller is operating inside a tenant, the narrower GET /business/accounts/{b2bAccountId}/transactions endpoint also exists — it returns the same shape but scoped to that tenant's IBANs. See Business Accounts (B2B) →.