Skip to main content
The REST API is in beta. Response shapes may change. These samples are kept in sync with the live API; the OpenAPI spec is the authoritative schema.
This page provides a full, self-consistent set of example JSON responses that you can paste into your code to test parsing, before you create a trial account or generate an API key. Every ID below is threaded end-to-end across the endpoints, so you can walk a realistic workflow — list connections, list accounts, fetch balances, transactions, holdings, trades — without making any network calls.
Every code block on this page has a copy button. Save the JSON as a local fixture file and run your parser against it. Once your parser handles every fixture on this page correctly, sign up and swap in real API calls.

​
About the IDs

  • Connection and account IDs are UUIDs generated by Redbark.
  • Transaction IDs come from the banking provider (Fiskil) and are opaque strings — treat them as arbitrary strings, not UUIDs.
  • Holding IDs are opaque strings from the brokerage provider (SnapTrade).
  • Trade IDs are opaque, snap_-prefixed strings built deterministically from a hash of core trade attributes, so they stay stable across fetches of the same trade. Treat them as opaque.
  • All decimal values (balances, amounts, quantities, prices) are returned as strings to preserve precision — parse them with a decimal library, not a float.

​
The scenario

Two connections belonging to the same user:

​
GET /v1/connections

Returns every active connection for the authenticated user. Connections with status deleting are excluded. Ordered by createdAt DESC (most recent first).
Possible status values: active, invalidated, pending_mfa, revoked. institutionLogo and lastRefreshedAt are nullable. institutionId is an opaque provider-specific identifier (numeric strings for Fiskil, UUIDs for SnapTrade) — treat it as an arbitrary string. See the Connections reference.

​
GET /v1/accounts

Returns every account across both connections in a single paginated response. Ordered alphabetically by account name (ASC).
Possible type values: transaction, savings, credit-card, loan, investment, term-deposit, other. Note the hyphen in credit-card (not credit_card).
provider, institutionName, and accountNumber are nullable. accountNumber is masked to the last 4 digits as xxxx<last4>. See the Accounts reference.

​
GET /v1/balances?accountIds=...

Balances for all four accounts. Accepts a comma-separated list of up to 100 account UUIDs. Returned in the order the provider responds (not guaranteed to match the input order). Request:
Response:
currentBalance, availableBalance, and currency are all nullable. If the provider call for a given account fails, those three fields come back as null for that account. Parsers must handle the null case.
currentBalance can be negative (e.g. credit cards, overdrawn accounts). See the Balances reference.

​
GET /v1/transactions?connectionId=...

Since the 2026-06-30 sunset, accountId is required: a call with only connectionId returns 410 account_id_required. Make one request per account and merge the results client-side. The combined response below covers the three Westpac accounts for the default 30-day window (one call each). Only transactions with status posted are returned; pending transactions are filtered out upstream at the provider. Request (repeat once per account):
Response:
The category field returns the raw CDR primary-category code (uppercase, underscored) exactly as supplied by the banking provider — not a human-readable label. Possible values: BANK_FEES, ENTERTAINMENT, FOOD_AND_DRINK, GOVERNMENT_AND_NON_PROFIT, HOME_IMPROVEMENT, INCOME, LOAN_PAYMENTS, MEDICAL, MERCHANDISE, PERSONAL_CARE, RENT_AND_UTILITIES, SERVICES, TRANSFER_IN, TRANSFER_OUT, TRANSPORTATION, TRAVEL. Not all transactions have a category — the field is nullable.
amount is a signed decimal string (negative for debits, positive for credits). direction is a convenience field: "credit" or "debit". Each transaction can carry three dates: date/datetime (the transaction/execution date, in your account timezone set in Settings and as a raw ISO 8601 timestamp), postDate/postDatetime (the posting/booking date that shows on your statement), and valueDate/valueDatetime (the value date, when funds clear). Key off postDate when reconciling against a bank’s running balance. postDate and valueDate are null when the provider omits them.
See the Transactions reference.

​
GET /v1/holdings?connectionId=...

Holdings for the Interactive Brokers trading account. Holdings are only available on brokerage connections and require a Professional plan. Requesting holdings for a banking connection returns 400. Request:
Response:
name, exchange, averagePrice, currentPrice, marketValue, and unrealizedPnl are all nullable — they depend on what the brokerage surfaces. Only symbol, currency, and quantity are guaranteed.
See the Holdings reference.

​
GET /v1/trades?connectionId=...

Trades on the IBKR account. pagination.total is null when hasMore is true (the total is only known once every page has been fetched). When hasMore is false, total is the exact count of returned trades. Request:
Response:
type is one of: buy, sell, dividend, split, transfer, fee, interest, other. Trade IDs are opaque, snap_-prefixed deterministic strings (a hash over core trade attributes, stable across fetches); treat them as opaque. name, fees, settlementDate, and description are nullable.
See the Trades reference.

​
Error responses

All errors return the same envelope regardless of endpoint:
code and details are optional and omitted entirely when not set — the server never emits "code": null or "details": []. The server emits a stable set of machine-readable codes (professional_required, invalid_params, connection_not_found, account_not_found, upstream_bad_request, upstream_breaker_open, client_disconnected, and others) — see the Overview for the full list. A 400 validation error on transactions includes details:
A 429 rate-limit error is accompanied by a Retry-After response header (seconds):
See the Overview for the full list of status codes.

​
Webhook payload (transactions.synced)

If you’re building a webhook destination consumer, here’s the envelope sent when a bank transaction sync completes. Payload formatting differs significantly from the REST API — notably, amounts are integers in the smallest currency unit (e.g. cents), all field names use snake_case, and timestamps in the envelope are Unix epoch seconds.
Brokerage syncs produce trades.synced events with the same envelope but trade objects in data.new; quantities, prices, and fees are decimal strings (not integers) to preserve precision for fractional shares. metadata.sync_run_id is a UUID for the sync run that produced the delivery, but is null when a delivery is replayed outside a sync run. See the Webhooks reference for payload fields, signature verification (HMAC-SHA256), chunking behaviour, and retry schedule.

​
Next steps

  • Validate your parser against every response above.
  • Pull the OpenAPI 3.1 spec and generate a typed client, or drive contract tests off it.
  • When you’re ready, create an API key and swap fixtures for real calls.