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: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
| Parameter | Type | Required | Description |
|---|---|---|---|
resource | string | Yes | Resource type to query. Must be one of: cards, account |
feature | string | Yes | Feature to retrieve (varies by resource, see tables below) |
currentPage | number | No | Current page number for pagination. Default: 0 |
pageSize | number | No | Number of items per page. Default: 10. Maximum: 100 |
startDate | string | No | Start date for filtering history (ISO 8601 format, e.g. 2024-01-01T00:00:00Z) |
endDate | string | No | End date for filtering history (ISO 8601 format) |
filterByText | string | No | Text filter for searching card transactions (e.g. merchant name, description) |
asOf | string | No | Snapshot date for certain features (ISO 8601 format). Used mainly with cards-summary |
Resource and Feature Combinations
Account resource
Whenresource=account, the following feature values are supported:
| Feature | Description |
|---|---|
account | Full account history (all supported transaction types) |
account-onramp | History of onramp (buy) operations |
account-offramp | History of offramp (sell) operations |
account-swap | History of swap/bridge operations |
account-crypto | History of crypto transfers (token transfers) |
account-portifolio | Aggregated portfolio-related history (transfers, swaps, bridges) |
Cards resource
Whenresource=cards, the following feature values are supported:
| Feature | Description |
|---|---|
cards-transactions | Paginated list of card transactions, including card metadata (last four digits, nickname, etc.) |
cards-summary | Snapshot of the user’s cards (status, spending limits, etc.) at a point in time (asOf) |
cards-balance | History of collateral movements and running card balance |
Responses
The response shape depends on the combination ofresource 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.
Status message (if present)
Array of account history entries. Each entry typically includes:
Entry ID
Date and time of the transaction (ISO 8601)
Type of transaction (e.g., buy, sell, swap-bridge, transfer-token)
Human-readable description of the transaction
Current status of the transaction
Amount involved in the operation
Asset sent (if applicable)
Amount sent (if applicable)
Asset received (if applicable)
Amount received (if applicable)
Running balance after this transaction
Execution timestamp (ISO 8601, nullable)
Purpose of the transaction
Optional user-provided description
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.
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.
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.
Same structure as other paginated responses.
Error Responses
Error message describing what went wrong
| Status Code | Error Message | Description |
|---|---|---|
400 | Invalid feature or validation error | The combination of resource/feature or other query params is invalid |
401 | Unauthorized: API key is required | The Authorization header is missing or not in the expected format |
401 | Unauthorized: Invalid API key | The provided API key is invalid |
429 | Rate limit exceeded | Too many requests for the same user in a short period |
500 | API key validation failed: ... | Internal error while validating the API key |
Rate Limits
The History API is rate-limited per user to protect the service and ensure fair usage. When you receive429 responses, implement retry logic with exponential backoff to avoid hammering the API.
Best Practices
- Use pagination: Always provide
currentPageandpageSizeto avoid fetching excessively large responses. - Filter by date: Use
startDate,endDate, andasOfto restrict the time window of data as much as possible. - Choose the right feature: Use
account-onramp,account-offramp,account-swap,account-crypto, oraccount-portifolioto narrow the type of account history you need. - Leverage text search: For card transactions, use
filterByTextto search by merchant or description instead of post-processing large datasets. - Handle rate limits: Implement exponential backoff and respect
429responses to keep your integration stable.
Support
For API support, please contact:- Email: [email protected]
- Dashboard: LootRush Dashboard