Filter transactions by status - Help Center

Retrieve only posted or only pending banking transactions, and handle the pending-to-posted lifecycle.

The GET /v1/banking/transactions endpoint supports filtering by transaction status, so you can exclude pending transactions server-side instead of filtering in your application.

Transaction statuses

Status	Meaning
`POSTED`	Fully processed and settled by the institution.
`PENDING`	Authorised but not yet settled. Common for card payments; the amount or description may change, or the transaction may be reversed, before it posts.

Why filter

Pending transactions can cause problems in applications that rely on final data:

Pending amounts may differ from the final posted amount.
A PENDING transaction may never post (for example, a pre-authorisation that expires).
Some institutions return the same transaction first as PENDING and later as POSTED, which can look like a duplicate.
Pending items described as PURCHASE or AUTHORISATION can confuse end users.

Use the status parameter

Pass status to the transactions endpoint:

GET /v1/banking/transactions?end_user_id={id}&status=POSTED

Use status=PENDING for pending transactions only. If status is omitted, transactions of all statuses are returned.

The parameter combines with from/to, account_id, and pagination — for example, posted transactions for one account over 30 days:

GET /v1/banking/transactions?end_user_id={id}&account_id={account_id}&status=POSTED&from=2025-06-01T00:00:00Z&to=2025-07-01T00:00:00Z

See Date ranges and pagination for the other parameters.

Bank feeds and cash flow products

If you power a bank feed or cash flow product, show POSTED transactions only where you can — pending amounts are provisional. If you do display pending transactions, label them clearly and refresh them regularly, since their status changes once settled.

Known status quirks

In Australia (CDR), institutions interpret pending and posted slightly differently, which produces some known quirks:

The transaction_id of a PENDING transaction is not guaranteed to match the transaction_id of the same transaction once POSTED.
Some transactions described as Authorisation appear as POSTED because the institution's internal ledger has cleared them before settlement; when they settle, the transaction_id can change again. This is a long-standing issue in the CDR standards.

If you see apparent duplicates across the pending-to-posted transition, see Missing or duplicate transactions.