Skip to main content

Overview

The History API allows third-party partners to query the transaction and activity history of the authenticated user. It supports both cards and account resources, with multiple features for summaries, transactions, balances, and filtered account activity.
All endpoints require authentication via the Authorization: Bearer <api_key> header. The user is inferred from the API key; you do not pass a userId in the URL.

Authentication

All requests must include an API key in the Authorization header:
Unauthorized requests (missing or invalid API key) will return a 401 Unauthorized response.

Get User History

Retrieves the transaction and activity history for the authenticated user. You can query either cards or account data, and choose which feature you want via query parameters.

Query Parameters

Resource and Feature Combinations

Account resource

When resource=account, the following feature values are supported: These features all return the same Activity shape, but filtered by transaction type internally.

Cards resource

When resource=cards, the following feature values are supported:

Responses

The response shape depends on the combination of resource and feature. Below are the main structures you will encounter.

Account History Response (resource=account)

For resource=account, you receive a list of account history entries and pagination info.
string
Status message (if present)
array
Array of account history entries. Each entry typically includes:
string
Entry ID
string
Date and time of the transaction (ISO 8601)
string
Raw transaction type: buy (deposit), sell (withdrawal), swap-bridge (convert), transfer-token (send)
string
Human-readable description of the transaction
string
Current status of the transaction
string
Amount involved in the operation
string
Asset sent (if applicable)
string
Amount sent (if applicable)
string
Asset received (if applicable)
string
Amount received (if applicable)
string
Running balance after this transaction
string
Execution timestamp (ISO 8601, nullable)
string
Purpose of the transaction
string
Optional user-provided description
object
Pagination information:
boolean
Whether there is another page of results
number
Current page index (starting from 0)
number
Number of items per page
number
Total number of pages available
number
Total number of records matching the query

Example Request (Account History)

Example Response (simplified)

Cards Transactions Response (resource=cards, feature=cards-transactions)

For cards-transactions, you receive card transactions enriched with card metadata.
array
Array of items with transaction and card information:
object
Card transaction details (amount, merchant, status, currency, etc.)
object
Card metadata:
string
Cardholder name
string
Card nickname
string
Last four digits of the card
object
Pagination information:
boolean
number
number
number
number

Example Request (Cards Transactions)

Example Response (simplified)

Cards Summary Response (resource=cards, feature=cards-summary)

For cards-summary, you receive a snapshot of the user’s cards and related limits.
array
Array of card snapshots with fields such as:
string
Card ID
string
Card nickname
string
Last four digits of the card
string
Card status
number
Spending limit associated with the card
string
Interval for the spending limit (e.g., monthly)
object
Same structure as other paginated responses.

Example Request (Cards Summary)

Cards Balance Response (resource=cards, feature=cards-balance)

For cards-balance, you receive card collateral movements and running balance over time.
array
Array of balance movement records:
number
Amount of the movement
number
Balance after the movement
number
Balance before the movement
string
Description of the movement
string
Timestamp of the movement (ISO 8601)
string
Movement type
object
Same structure as other paginated responses.

Error Responses

string
Error message describing what went wrong

Rate Limits

The History API is rate-limited per user to protect the service and ensure fair usage.
Each user can perform up to 2 requests every 2 seconds. Exceeding this limit will result in a 429 Rate limit exceeded error.
When you receive 429 responses, implement retry logic with exponential backoff to avoid hammering the API.

Best Practices

  1. Use pagination: Always provide currentPage and pageSize to avoid fetching excessively large responses.
  2. Filter by date: Use startDate, endDate, and asOf to restrict the time window of data as much as possible.
  3. Choose the right feature: Use account-onramp, account-offramp, account-swap, account-crypto, or account-portifolio to narrow the type of account history you need.
  4. Leverage text search: For card transactions, use filterByText to search by merchant or description instead of post-processing large datasets.
  5. Handle rate limits: Implement exponential backoff and respect 429 responses to keep your integration stable.

Support

For API support, please contact: