Skip to main content
​
Account history no longer returns internal processing fields

​
Fewer internal fields in account history

Entries from GET /api/history with resource=account no longer include a few internal processing fields that were never part of the documented response. Every documented field is unchanged, and so is the payment and provider data each entry carries. If you don’t read undocumented fields, there is nothing to change on your side.
​
Change or move many cards in one call

​
Batch card changes on the MCP server

Two new tools take a list of up to 25 cards, so changing many cards no longer means one call per card (and one second per card under the rate limit). Both need an mcp:write key.
  • updateUserCards applies the same status (active, inactive, locked), spending limit or interval to every card in the list. Canceling stays one card at a time, with updateUserCard.
  • moveCardsToGroup moves every card in the list into the same group, or takes them out of their groups.
Each card gets its own result — updated/moved, failed with a code, or notAttempted — so a partly finished call tells you exactly which cards to send again. See updateUserCards and moveCardsToGroup.
​
The MCP server can now read and manage card groups

​
Card groups on the MCP server

Eight new tools let an assistant work with card groups: list them, follow a group-wide change, and — with an mcp:write key — create, change and delete them. See Card groups.Reading (the mcp scope is enough):
  • getCardGroups lists your groups with their card count, locked cards, total spending limit and 30-day spend.
  • getCardGroupJobs follows a lock, unlock or cancel that is running in the background.
  • getCardSpendReport reports spend over a date range by group, by card and by who created each card.
Writing (needs mcp:write):
  • createCardGroup and updateCardGroup create a group, rename it, and change its description.
  • moveCardToGroup puts a card into a group, moves it, or takes it out.
  • setCardGroupCardsStatus locks or unlocks every card in a group in one call. It returns a jobId straight away; follow it with getCardGroupJobs.
  • deleteCardGroup deletes a group and keeps its cards. With cancelCards: true it cancels every card in the group first — permanently.
The existing card tools understand groups too:
  • getUserCards, getUserCardTransactions and getUserCardSummary take a groupId filter, and every card carries groupId and groupName.
  • createUserCards takes a groupId to create cards straight into a group.
  • aggregate can group and filter card transactions by groupName. Spend on cards outside any group is reported as (no group).
A group-wide lock, unlock or cancel counts as one call against the rate limit, however many cards the group holds. A role limited to specific card groups sees and changes only those groups’ cards.
​
Account history now returns the settlement date and notes shown in the statement export

​
resource=account: the same dates and descriptions as the statement export

Several fields on account history entries came back empty even though the statement export filled them. They are now populated from the same data:
  • executedAt is when the transaction settled, which was always empty before. It can be later than the creation date: a payment created on one day and settled on another carries the settlement day here, as the export’s “Executed At” column does. If you group transactions by day, use this field.
  • description now ends with any note added to the transaction afterwards, after -, as it does in the export. The note alone is in the new additionalDescription field.
  • userDescription returns the memo entered when the transaction was created. It was always null before.
  • transactionPurpose returns the purpose given for a withdrawal. It was always empty before.
  • fiatExecutedAt is new: for deposits and withdrawals, it is when the fiat side was processed.
If your integration used the creation date because executedAt was empty, transactions that settled on a later day may be filed under the wrong day. Re-run those days using executedAt.
​
The MCP server can now create and change cards, with an mcp:write key

​
createUserCards and updateUserCard — the first writes

The MCP server used to be read-only. Two tools now change something, and both need the new mcp:write scope, checked on every call. Existing keys are unaffected: without the scope a key connects exactly as before, and is refused only when a write is attempted.Scopes are fixed when a key is created and can’t be added to an existing one. To start writing, create a new key at Settings → API keys with MCP + Write selected, then revoke the old one.

​
createUserCards

Creates one card, or queues a batch of up to 30. A single card comes back immediately; a batch doesn’t, since issuing thirty cards outlives the request. You get a batchId instead, and call the same tool with that id to read the batch’s progress (cardsCreated, cardsFailed, cardIds). Nothing is created when batchId is set.Retrying is safe without an idempotency key: a batch already running with the same recipe and size is returned (alreadyRunning: true) rather than queued a second time.Name a batch with nicknamePrefix (plus optional nicknameStartAt and nicknamePadding) — nickname would repeat the same label on all 30 cards.Bulk is a business-account feature. Without it, a quantity above 1 creates one card and the response says so — created, requested and bulkUnavailable: true, alongside the card.

​
updateUserCard

Changes one card per call: status, nickname, spendingLimit, spendingInterval. It returns the card’s state after the change, so you don’t have to list cards again to see the result.canceled is permanent. To stop a card temporarily, use inactive or locked — both reversible with active.

​
One less id to pass

You no longer need to send a cardIssuerUserId: if your account has a single card-issuer account it’s filled in for you. If it holds more than one, the tool lists the ids you can choose from.
​
getCashbackSummary: cashback, with pending broken out

​
getCashbackSummary — your LootRush Rewards cashback

Cashback was visible on the site but nowhere in the API. The new getCashbackSummary returns it across every enrolled card-issuer account, and it also comes back as a cashback section on getAccountBalance and getUserCards — the same treatment cardBalance gets.

​
Four cashback balances, not one “pending”

Cashback isn’t a single balance with a pending amount. It has four states, and only one of them is money the cardholder can use today:total is the headline (available + redeeming), taken as-is from the same source the site shows, so it can’t drift from it.Also returned: expiring (the soonest slice about to lapse), and monthProgress — this month’s spend buckets with their rate ladder, which is what answers “what rate am I on”.

​
enrolled: false is not “zero”

An account with no cashback-active card issuer gets zeros and enrolled: false. Those zeros mean cashback is not switched on, which is a different answer from earned nothing. Read the flag before quoting the number.

​
No card ids

The tool takes no cardId or cardIssuerUserId — enrollment is resolved from your identity server-side. The only parameter is an optional month (YYYY-MM) for the rate ladder.

​
Currencies are never added together

If your accounts disagree about currency, the headline fields stay zero and a byCurrency array carries the real per-currency split.
​
aggregate: totals without paging

​
aggregate — totals over your whole slice, in one call

The listing tools return rows, so answering “how much did I spend last month” meant paging every one of them and adding up client-side — slow, and wrong the moment a page is missed. The new aggregate tool returns the number instead, computed over the whole filtered set.
  • Ops: sum, count, avg, min, max, median.
  • Break it down by a column (groupBy) or by time (timeBucket: day, week, month).
  • Sources: cardTransactions and accountHistory.

​
Listing responses now carry a datasetId

getUserCardTransactions and getAccountHistory return a datasetId alongside their rows, plus aggregatable, groupable and ops describing what you can ask of them.Pass that handle to aggregate and the total covers exactly the slice you just listed — the handle stores that call’s filters, never its rows, and expires after 15 minutes. You can also skip the listing entirely and pass source + filters straight to aggregate.

​
Three things to know about the numbers

  • A partial result says so. If the slice exceeded the row cap the response carries complete: false with the coverage it does have. Check it before quoting the number.
  • Currencies are never merged. Amounts in different currencies come back as separate entries.
  • Declined card attempts don’t count as spend. Money columns on cardTransactions are split by status unless you pin one — only settled (and on_hold, still authorising) is money that left the account.
Read-only and scoped to your own account, like every other tool.
​
MCP card tools + card balance

​
New card tools on the MCP server

Three new read-only tools give your AI assistant a full view of your card balance and its history — the data the LootRush app shows, now available over MCP.
  • getUserCardBalanceMovements — your card balance (collateral) ledger. Each entry carries its running balance and previous balance — the statement-style running total that card transactions don’t include. Results are grouped per card issuer so each running-balance series stays coherent. Optional cardIssuerUserId, page/pageSize, startDate/endDate.
  • getUserCardSummary — a point-in-time snapshot of your cards: per-card balance, status, and limits as of any instant (asOf, defaults to now).
  • getUserCardBalanceAutomation — your spending-limit auto-refill history: each automatic balance top-up (amount, status, retries, on-chain tx hash, and when it ran).
All three are read-only and scoped to your own account.

​
Card balance now in getAccountBalance and getUserCards

Both tools now return a normalized cardBalance block — { total, pendingDeposit, pendingWithdraw } — the card collateral shared across your cards. In getAccountBalance it is reported as its own bucket and is not added into totalUsdValue (which stays crypto + tokenized + available wallet stablecoins).The getAccountBalance reference now also covers the availableStableUsdValue and stableCoins fields (your live on-chain wallet stablecoins), and getUserCards returns the raw balances payload alongside cardBalance when you need the licensed / non-licensed split.See the MCP Server reference for the full field and parameter tables.