List Transactions

The REST API is in beta. This endpoint’s response shape may change.

Returns a paginated list of transactions for a given connection. By default only posted (settled) transactions are returned; pass includePending=true to also include pending transactions. Transactions are fetched live from the banking provider. No transaction data is stored on Redbark servers.

Request

GET /v1/transactions

Headers

Header	Required	Description
`Authorization`	Yes	`Bearer YOUR_API_KEY`

Trialing customers retain full API access, including brokerage endpoints, regardless of trial plan.

Response headers

Header	Description
`X-Redbark-Truncated`	`true` if the ~5,000-row ceiling fired (see Response limits).
`Deprecation` / `Sunset`	Set on the removed connectionId-only form (omitted `accountId`), which now returns `410 Gone`.

Caching

Transactions may be served from a short-lived server-side cache for up to 60 minutes. Cached data is purged immediately on consent revocation or connection deletion, and you can opt out entirely in app settings; see Caching.

Query parameters

Parameter	Type	Required	Default	Description
`connectionId`	`string`	Yes		Connection to fetch transactions from
`accountId`	`string`	Yes		Account to fetch. The connectionId-only (all-accounts) form was removed on 2026-06-30 and now returns `410 Gone` with code `account_id_required`.
`from`	`string`	No	30 days ago	Start of the window (`YYYY-MM-DD` or ISO 8601), inclusive. Filters on the transaction (execution) date, falling back to the posting date when the provider omits it, evaluated in your account’s timezone.
`to`	`string`	No	Now	End of the window (`YYYY-MM-DD` or ISO 8601), inclusive. Same date basis as `from`.
`includePending`	`boolean`	No	`false`	When `true`, include pending (not-yet-settled) transactions alongside posted ones. Pending rows carry `status: "pending"`, may have a `null` `postDate`, and are provisional — read Pending transactions before relying on them, as their `id` and details change when they settle. Omit (or pass `false`) for posted-only.
`limit`	`integer`	No	`200`	Maximum items to return (1 to 500)
`offset`	`integer`	No	`0`	Number of items to skip

connectionId and accountId are both required. Use List Connections for connection IDs and List Accounts for account IDs.

The all-accounts form (omitting accountId) was removed on 2026-06-30. It now returns 410 Gone with code account_id_required, alongside Deprecation: true and Sunset: Tue, 30 Jun 2026 23:59:59 GMT headers. Pass accountId (one request per account); list a connection’s accounts via List Accounts.

Response limits

To bound memory under wide date ranges, the service stops fetching upstream pages once it has roughly 5,000 matching rows for a single request. When this row ceiling fires:

The response sets X-Redbark-Truncated: true.
pagination.hasMore is true and pagination.total is a lower bound rather than the exact count.
Continue paginating with the next offset + limit window — the same cap applies per request, not per session.

Separately, each account is fetched with a per-request page cap of ceil((offset + limit) / 1000) + 2 upstream pages. This cap does not set X-Redbark-Truncated. In an unusually dense date window it can stop paging before the window is exhausted and return a page with hasMore: false that under-reports the total. If you need every row in a very dense window, narrow the date range and page through smaller windows.

Pending transactions

By default this endpoint returns only posted (settled) transactions. Pass includePending=true to also include pending ones, which appear with status: "pending".

Pending transactions are provisional — do not treat them as stable records. Under the Open Banking (CDR) standard there is no guarantee that a pending transaction can be correlated with the posted transaction it later becomes. In practice this means:

The id changes when a transaction settles. A pending transaction and its eventual posted version are two separate records with two different id values. There is no shared key linking them. If you upsert by id, a purchase you already stored as pending will land again as a brand-new posted row.
A pending transaction can disappear entirely. An authorisation hold that is reversed, declined, or voided may vanish without ever posting.
The details can change on settlement. amount, description, date, postDate, category, and merchantName may all differ once the transaction posts (e.g. a tip or currency-conversion adjustment changes the final amount).
postDate / postDatetime are usually null while a transaction is pending, since it hasn’t been booked to the account yet.

Recommended usage:

Reconcile on posted transactions. Treat posted rows as the source of truth for balances, exports, and anything you persist. Pending is best used as a read-only, real-time preview.
Don’t dedupe a pending row against its posted row by id — there is no reliable link. If you need to approximate one, match on a tuple like accountId + amount + a fuzzy date window and accept that it is heuristic, not exact.
Expect churn. Re-fetching the same window will add, remove, and mutate pending rows between calls. Cached responses (up to 60 minutes; see Caching) can also lag the current pending set.

Response

{
  "data": [
    {
      "id": "e4a7f91b2c3d4e5f6a7b8c9d",
      "accountId": "a1b2c3d4-e5f6-7890-a1b2-c3d4e5f67890",
      "accountName": "Everyday Account",
      "status": "posted",
      "date": "2026-03-12",
      "datetime": "2026-03-11T13:00:00.000Z",
      "postDate": "2026-03-12",
      "postDatetime": "2026-03-12T02:00:00.000Z",
      "valueDate": "2026-03-12",
      "valueDatetime": "2026-03-12T02:00:00.000Z",
      "description": "Woolworths Sydney",
      "amount": "-45.50",
      "direction": "debit",
      "category": "FOOD_AND_DRINK",
      "merchantName": "Woolworths",
      "merchantCategoryCode": null
    },
    {
      "id": "f5b8a02c3d4e5f6a7b8c9d0e",
      "accountId": "a1b2c3d4-e5f6-7890-a1b2-c3d4e5f67890",
      "accountName": "Everyday Account",
      "status": "posted",
      "date": "2026-03-11",
      "datetime": "2026-03-10T13:00:00.000Z",
      "postDate": "2026-03-11",
      "postDatetime": "2026-03-11T01:00:00.000Z",
      "valueDate": "2026-03-11",
      "valueDatetime": "2026-03-11T01:00:00.000Z",
      "description": "Salary Payment",
      "amount": "3500.00",
      "direction": "credit",
      "category": "INCOME",
      "merchantName": null,
      "merchantCategoryCode": null
    }
  ],
  "pagination": {
    "total": 87,
    "limit": 200,
    "offset": 0,
    "hasMore": false
  }
}

Transaction object

Field	Type	Description
`id`	`string`	Opaque transaction identifier from the banking provider. Treat as an arbitrary string.
`accountId`	`string`	UUID of the account this transaction belongs to
`accountName`	`string`	Account display name
`status`	`string`	`"posted"` or `"pending"`. Only `"posted"` is returned by default; `"pending"` appears when the request sets `includePending=true`. The response schema permits any string up to 64 chars.
`date`	`string`	Transaction date in your account’s timezone (`YYYY-MM-DD`): when the transaction occurred (the provider’s transaction/execution date). Defaults to `Australia/Sydney` if no timezone is set. Change your timezone in Settings.
`datetime`	`string \| null`	Raw ISO 8601 transaction timestamp from the banking provider (the same instant as `date`, before timezone conversion). Use this if you need to handle timezone conversion yourself.
`postDate`	`string \| null`	Posting (booking) date in your account’s timezone (`YYYY-MM-DD`): when the transaction was booked to the account and appears on a standard bank statement. Use this to reconcile against your bank’s per-day running balance. `null` if the provider didn’t supply a posting date.
`postDatetime`	`string \| null`	Raw ISO 8601 posting timestamp from the banking provider (the same instant as `postDate`, before timezone conversion), or `null`.
`valueDate`	`string \| null`	Value date in your account’s timezone (`YYYY-MM-DD`): the date funds become available (a credit) or leave the account (a debit), per the CDR `valueDateTime`. `null` if the provider didn’t supply one (many AU banks omit it).
`valueDatetime`	`string \| null`	Raw ISO 8601 value-date timestamp from the banking provider (the same instant as `valueDate`, before timezone conversion), or `null`.
`description`	`string`	Transaction description
`amount`	`string`	Signed decimal string (e.g. `"-45.50"`). Negative for debits, positive for credits.
`direction`	`string`	`"credit"` or `"debit"` (convenience field matching the sign of `amount`)
`category`	`string \| null`	Raw CDR primary-category code (see list below). Not all transactions have a category.
`merchantName`	`string \| null`	Merchant name, if available
`merchantCategoryCode`	`string \| null`	Merchant category code (MCC), if available

Three dates, three meanings. A transaction can carry up to three dates from the CDR feed, and they can differ (e.g. a weekend card purchase that books on the next business day):

date/datetime: the transaction (execution) date, i.e. when the transaction occurred.
postDate/postDatetime: the posting (booking) date, i.e. when it landed on the account and showed up on your statement. Key off postDate when reconciling against a bank’s per-day running balance.
valueDate/valueDatetime: the value date, i.e. when the funds actually become available or leave the account.

For most everyday transactions all three fall on the same day. postDate and valueDate are null when the provider doesn’t supply them (many AU banks omit the value date).

The amount field is a string to preserve decimal precision. Parse it as a decimal in your application — not a float.

`category` value	Human-readable label
`BANK_FEES`	Bank Fees
`ENTERTAINMENT`	Entertainment
`FOOD_AND_DRINK`	Food & Drink
`GOVERNMENT_AND_NON_PROFIT`	Government & Non-Profit
`HOME_IMPROVEMENT`	Home Improvement
`INCOME`	Income
`LOAN_PAYMENTS`	Loan Payments
`MEDICAL`	Medical
`MERCHANDISE`	Merchandise
`PERSONAL_CARE`	Personal Care
`RENT_AND_UTILITIES`	Rent & Utilities
`SERVICES`	Services
`TRANSFER_IN`	Transfer In
`TRANSFER_OUT`	Transfer Out
`TRANSPORTATION`	Transportation
`TRAVEL`	Travel

Pagination object

Field	Type	Description
`total`	`integer`	Count of transactions seen by the service for the filters (posted only, or posted plus pending when `includePending=true`). Always a number on this endpoint. When `hasMore` is `true` the service may have stopped paging early, so `total` is a lower bound. When `hasMore` is `false`, `total` is exact.
`limit`	`integer`	Limit applied to this request
`offset`	`integer`	Offset applied to this request
`hasMore`	`boolean`	`true` if more items exist beyond this page

Error responses

Errors use the standard envelope { "error": { "message": string, "code"?: string, "details"?: string[] } }. The optional code field is set for the structured cases below — clients should branch on code rather than parsing message.

Status	`code`	When
`400`	(none)	Missing `connectionId` (fails schema validation; returns the generic `Invalid request parameters` envelope with no `code`).
`410`	`account_id_required`	The all-accounts form (omitted `accountId`) was removed on 2026-06-30. Pass `accountId`.
`400`	(none)	Invalid date format (`details[]` lists the offending fields)
`400`	`invalid_date_range`	`Invalid date range:` from`must be on or before`to“
`400`	`from_too_old`	`from` is too far in the past — banking providers serve at most ~7 years of history
`400`	`wrong_endpoint_for_category`	`Transactions are only available for banking and documents connections. Use /v1/trades for brokerage connections.`
`404`	`connection_not_found` / `account_not_found`	Connection or account not found, or does not belong to you
`429`	(none)	Rate limit exceeded — heavy bucket is 30/min per API key, plus a per-key cap of 4 concurrent in-flight requests (excess returns `Too many concurrent requests`). See `Retry-After` and `X-RateLimit-Reset`.
`503`	(none)	Banking provider temporarily unavailable. `Retry-After: 30`.
`503`	`upstream_breaker_open`	After 3 upstream failures within a 60s window for the same `userId+connectionId`, subsequent requests fail fast for ~60s. `Retry-After` reflects the remaining cooldown.

Example error body:

{
  "error": {
    "message": "`from` is too far in the past — banking providers serve at most ~7 years of history",
    "code": "from_too_old"
  }
}

Date validation

The from and to parameters accept:

Date strings: 2026-03-01
Full ISO 8601 / RFC 3339 with explicit timezone: 2026-03-01T00:00:00Z or 2026-03-01T00:00:00+10:00

Naive datetimes with no Z and no ±HH:MM offset are explicitly rejected. Invalid formats return a 400 with details:

{
  "error": {
    "message": "Invalid date parameters",
    "details": [
      "from: Must be YYYY-MM-DD or RFC3339 with timezone (e.g. 2026-05-09T23:35:19Z or 2026-05-09T23:35:19+10:00)"
    ]
  }
}

Examples

Transactions for an account (last 30 days)

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.redbark.com/v1/transactions?connectionId=b7c4a1e2-8d3f-4e9a-9c5b-1f2a3e4d5c6b&accountId=a1b2c3d4-e5f6-7890-a1b2-c3d4e5f67890"

Filter by account and date range

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.redbark.com/v1/transactions?connectionId=b7c4a1e2-8d3f-4e9a-9c5b-1f2a3e4d5c6b&accountId=a1b2c3d4-e5f6-7890-a1b2-c3d4e5f67890&from=2026-01-01&to=2026-03-01"

Paginate

curl -H "Authorization: Bearer YOUR_API_KEY" \
  "https://api.redbark.com/v1/transactions?connectionId=b7c4a1e2-8d3f-4e9a-9c5b-1f2a3e4d5c6b&accountId=a1b2c3d4-e5f6-7890-a1b2-c3d4e5f67890&limit=50&offset=50"

Python: fetch all pages

import requests

API_KEY = "YOUR_API_KEY"
BASE = "https://api.redbark.com"

all_transactions = []
offset = 0
limit = 200

while True:
    resp = requests.get(
        f"{BASE}/v1/transactions",
        headers={"Authorization": f"Bearer {API_KEY}"},
        params={
            "connectionId": "b7c4a1e2-8d3f-4e9a-9c5b-1f2a3e4d5c6b",
            "accountId": "a1b2c3d4-e5f6-7890-a1b2-c3d4e5f67890",
            "from": "2026-01-01",
            "to": "2026-03-13",
            "limit": limit,
            "offset": offset,
        },
    )
    data = resp.json()
    all_transactions.extend(data["data"])

    if not data["pagination"]["hasMore"]:
        break
    offset += limit

print(f"Fetched {len(all_transactions)} transactions")

JavaScript: fetch all pages

const API_KEY = "YOUR_API_KEY";
const BASE = "https://api.redbark.com";

const allTransactions = [];
let offset = 0;
const limit = 200;

while (true) {
  const params = new URLSearchParams({
    connectionId: "b7c4a1e2-8d3f-4e9a-9c5b-1f2a3e4d5c6b",
    accountId: "a1b2c3d4-e5f6-7890-a1b2-c3d4e5f67890",
    from: "2026-01-01",
    to: "2026-03-13",
    limit: String(limit),
    offset: String(offset),
  });

  const resp = await fetch(`${BASE}/v1/transactions?${params}`, {
    headers: { Authorization: `Bearer ${API_KEY}` },
  });
  const { data, pagination } = await resp.json();

  allTransactions.push(...data);

  if (!pagination.hasMore) break;
  offset += limit;
}

console.log(`Fetched ${allTransactions.length} transactions`);

Overview

Endpoints

CLI

MCP Server

Webhooks

Request

Headers

Response headers

Caching

Query parameters

Response limits

Pending transactions

Response

Transaction object

Categories

Error responses

Date validation

Examples

Transactions for an account (last 30 days)

Filter by account and date range

Paginate

Python: fetch all pages

JavaScript: fetch all pages

​Request

​Headers

​Response headers

​Caching

​Query parameters

​Response limits

​Pending transactions

​Response

​Transaction object

​Categories

​Pagination object

​Error responses

​Date validation

​Examples

​Transactions for an account (last 30 days)

​Filter by account and date range

​Paginate

​Python: fetch all pages

​JavaScript: fetch all pages

Request

Headers

Response headers

Caching

Query parameters

Response limits

Pending transactions

Response

Transaction object

Categories

Pagination object

Error responses

Date validation

Examples

Transactions for an account (last 30 days)

Filter by account and date range

Paginate

Python: fetch all pages

JavaScript: fetch all pages