The Management API has a family of read-only search endpoints with one shared shape. All of them:
  • take comma-separated values on every filter for multi-select,
  • paginate with page (default 1) and limit,
  • require programId,
  • and can export instead of returning JSON: pass resultType=file and you get a presigned S3 CSV URL (valid 1 hour) in place of the data array (filePrefix customises the filename).
Responses share a flat envelope, with pagination alongside the results:
Not every endpoint takes every shared filter — keyword and the date-range parameters in particular vary. Each API Reference page lists exactly what its endpoint accepts.
Each endpoint below links to its API Reference page, where you can inspect the full schema and send a live request with the Try it playground.

​
The endpoints

​
Defaults worth knowing

GET /v1/payments/requests does not return everything by default. With no status filter it returns only PENDING, PENDING_TM, INITIATED and PENDING_CANCELLATION — pass an explicit status list to see anything else.Its date filters are also startDate / endDate, not fromDate / toDate. The fromDate/toDate names are ignored here, so a request carrying them silently searches an unbounded range rather than failing.
GET /v1/accounts does not accept keyword — use the specific identifier filters (accountId, iban, accountNumber, accountProviderAccountId, accountName). Accounts in PENDING status are always excluded, whatever status you pass. allPrograms has no effect on it: programId always sets the program scope.

​
Payment-request export columns (changed)

GET /v1/payments/requests now returns a defined field set instead of the stored record. Previously the response — and the resultType=file CSV built from it — carried whatever the search index happened to hold, so any key the indexer wrote could turn up as a column. Both now follow the documented shape: the CSV columns are drawn from a fixed, documented set of fields, and which of them appear still depends on the rows returned — json-2-csv builds the header from the keys present across them, so an export of only FEE and CARD rows carries no payee.* columns.Columns removed from the export (and fields removed from the JSON response). This list is exhaustive — it is the full difference against the stored record, not against the published PaymentRequest schema:Nothing used for provider reconciliation or support was removed. providerRequestId, endToEndReference, originalEndToEndReference, providerStatus, entity, custodianId, debtorViban, batchItemId, batchId, unloadId, childAccountId, purpose and updatedAt are all still returned, alongside programId, subType and transactionMonitoring. So is payee.currency, which on an international payout is the target currency the beneficiary was credited in — the top-level currency is the source we debited, and the two are deliberately different. If you match exports against a provider, or attribute a prepaid master-account row to its child, the keys you match on are unchanged.originalEndToEndReference matters most where reconciliation is hardest: when a cancellation at the bank burns the original end-to-end id and the payment is re-submitted, endToEndReference holds the id actually sent on the wire and originalEndToEndReference preserves the one the provider first saw.The SEPA direct-debit cancellation context is still returned too — priorStatusBeforeCancellation, cancellationRequestedAt, cancellationReasonCode and cancellationSource. PENDING_CANCELLATION is one of the default statuses, so those rows are in the default result set.CSV column shapes are unchanged. statusHistory is still flattened one column per entry — statusHistory.0.status, statusHistory.1.status, … — so existing sheets and parsers keep working. Column order does change, though: it now follows the documented field order rather than the stored record’s key order. Parsers that read columns by name are unaffected; positional ones are not.Two corrections apply to the JSON response: statusHistory is now always an array (it could previously arrive as an object keyed "0", "1", …), and isDirectDebit is always present as a boolean rather than sometimes absent — so it now appears on every row of the export, not only on rows that stamped it.

​
Program scope

programId is required on every search, including when you pass allPrograms=true. That flag widens the search from one program to every program your operator role is entitled to — it does not replace programId, and it never reaches beyond your entitlements. A role with no program entitlement matches nothing rather than everything. On GET /v1/accounts the flag has no effect at all: that endpoint always scopes to the programId you pass.