Get user history
Retrieves transaction and activity history for the authenticated user. The user is inferred from the API key; no userId is passed. Choose the data set with resource + feature. For resource=account the payload is the account ledger and reconciles line for line against the CSV/PDF account statement for the same period. Anything not yet settled — a withdrawal still processing, a purchase awaiting payment, a rejected order — is deliberately NOT in it, and is served by feature=account-unsettled instead. Read both to see everything an account did; they never overlap. Rate limited to 2 requests every 2 seconds per user.
Authorizations
API token issued by your LootRush account manager. Sent as Authorization: Bearer <token>.
Query Parameters
Resource type to query.
cards, account Which data set to return.
Account — the two halves of an account's activity. Every record is in exactly one of them, so they can be read together without double-counting.
account— the LEDGER: everything that settled. One node per ledger line, the same lines the CSV/PDF account statement writes for the same period. This is what you reconcile against.account-unsettled— everything that has NOT settled and so appears nowhere in the ledger or the statement: awaiting payment, pending, in analysis, started, rejected. Some of these will settle and move toaccount; the terminal ones (rejected, canceled) never will. This is where a withdrawal lives between being requested and reaching the ledger.
Account, filtered by kind — subsets of account, same ledger, one operation type each:
account-onramp(deposits),account-offramp(withdrawals),account-swap(converts),account-crypto(crypto transfers and sends),account-portifolio(portfolio activity).
Cards:
cards-transactions(card transactions),cards-summary(card snapshot, seeasOfandstatus),cards-balance(balance movements per card).
account, account-unsettled, account-onramp, account-offramp, account-swap, account-crypto, account-portifolio, cards-transactions, cards-summary, cards-balance Page number (0-indexed). Pages through the whole result set: there is no depth limit, and no page returns fewer than pageSize items unless it is the last one.
Items per page.
x <= 200Start of the date window (ISO 8601).
End of the date window (ISO 8601).
Text filter for card transactions (merchant, description).
Snapshot date (ISO 8601). Used mainly with cards-summary.
Card status filter, for cards-summary only. Omitted, the snapshot returns only the cards still visible to the cardholder — canceled cards are hidden. Use all for every card regardless of status, or a single status to filter by it.
all, active, inactive, locked, canceled Response
History payload. Shape depends on resource + feature (account history nodes, card transactions, card snapshots, or balance movements). For resource=account the payload is one node per ledger line — the same lines, and the same set of them, that the CSV/PDF account statement writes for the same period, ordered newest first (the reverse of the statement). A cross-chain swap or bridge therefore appears as one node per leg. Two keys per node, and they answer different questions. uniqueHashId is {transactionHash}:{logIndex} — the line's identity on chain: unique per node, stable across calls, and what you reconcile and de-duplicate on. id is the operation the line belongs to, so the two legs of a cross-chain swap share it; it is NOT unique per node, and it is also the value that ties a record here to the same record in account-unsettled before it settled. A line with no on-chain identity gets an opaque unique uniqueHashId instead, or null if it has no key at all — never a shared placeholder. pageInfo.totalCount is an exact count of the nodes the query can serve, and pageInfo.totalCountIsEstimate is always false, retained for backwards compatibility. Trades still pending on-chain are not included — a withdrawal appears once it reaches the ledger, exactly as in the statement.
The response is of type object.