Skip to main content
GET
List Transactions

Overview

Returns your Bill Payment transactions, newest first. Use it for reconciliation, for a history screen, and for finding a transaction when you have lost its identifier and its reference. The list is scoped to your own account and to the environment of the key you send: a sandbox key never sees production transactions, and vice versa.
data is a plain array of transaction objects. The counts live in meta: total, limit and offset.

Query Parameters

string
Filter by status. One of PENDING, READY, PROCESSING, SUCCESS, FAILED, REFUNDED, UNKNOWN.
string
Filter by biller. One of ADE, SONELGAZ, SEAAL, AADL, Algérie Télécom.
string
Only transactions created on or after this instant. An ISO 8601 date or date-time, for example 2026-08-01 or 2026-08-01T00:00:00Z.
string
Only transactions created on or before this instant. Same format as from.
integer
default:"20"
Page size, between 1 and 100.
integer
default:"0"
How many transactions to skip. Zero or more.
There is no ref filter on this endpoint. To find a transaction by your own reference, use Get Transaction by Reference.

Response

boolean
required
true when the page was returned.
array
required
An array of transaction objects, newest first. Each entry has exactly the shape documented on Get Transaction by ID — including the rule that bills, selectedBill, receiptUrl, operationId and error appear only in the statuses where they are meaningful.An empty array means no transaction matched.
object
required
string
required
Correlation identifier, also sent as the X-Request-Id response header.

Examples

Success Response

Error Responses

A filter value was not accepted.
Common causes: a status or partner outside the allowed set, a from or to that is not an ISO 8601 date, a limit above 100 or below 1, a negative offset.What to do: fix the query string. Values are case-sensitive.
The key was absent or rejected.
What to do: verify the key with Validate API Key.
We could not verify your key in time, or the API is in planned maintenance.
What to do: honour the Retry-After header (5 seconds) and retry. Listing is always safe to repeat.

Paging through a period

meta.total is the count for the filters you sent, so you can page until you have seen all of it. Keep the page size modest and the window bounded.
New transactions are created while you page. For reconciliation, always bound the window with from and to so the result set cannot grow underneath you.

What the list contains

Both discoveries and payments appear here. type tells them apart:
  • type: "discovery" — a lookup that has not been paid. Its status is PENDING, READY or FAILED.
  • type: "payment" — a discovery that a payment was submitted against. Its status is PROCESSING, SUCCESS, FAILED, REFUNDED or UNKNOWN.
A transaction becomes a payment in place, keeping its transactionId and its original ref.

Best Practices

Bound every query

Always send from and to for reconciliation. An unbounded list grows with your business.

Reconcile on SUCCESS and REFUNDED

Those two statuses are where money moved. FAILED never moved any.

Do not poll this endpoint

To follow one transaction, poll it by identifier. Listing repeatedly is slower and heavier for both sides.

Read meta.total

It is the count for your filters, and the only way to know whether another page exists.

Get Transaction by ID

The full transaction object

Get Transaction by Reference

Look up by your own ref

Download Receipt

Proof for a paid transaction

Receipts and Reconciliation

A daily reconciliation routine