Spendesk cards are created from approved spend requests, and every payment made with them is recorded as a transaction — settled, or declined. Through the API you can:

• follow the cards — balances, limits, subscription budgets, who holds them, why one is blocked;
• follow the requests behind them — what is waiting for approval, and who has to approve it;
• follow card payments — settled transactions for reconciliation, declined ones to help cardholders.

📘

Experimental

Card, request and transaction endpoints are experimental: they may still change. Request access from your CSM or at [email protected] — see Getting access.

Before you start

• Scopes: experimental:card:read for cards, experimental:request:read for requests, experimental:transaction:read for transactions. All these endpoints only read data.
• With an organisation-level key, send the X-Company-Id header on every call — see Organisation-level access.

Try it in Postman. The companion collection Spendesk API — Card spend guide runs every request of this page in order, passing IDs from one to the next; it only reads data. Fork it, select the Spendesk Sandbox environment, fill in clientId, clientSecret — and companyId with an organisation-level credential — then follow the ▶️ links below.

How it fits together

1. An employee asks for a card with a spend request — a single purchase, a subscription, a multi-use card, or a top-up.
2. Once approved, the request becomes a card.
3. Each payment with the card is a transaction: settled when it goes through, declined when it does not.
4. Settled payments then become payables, prepared and exported like any other spend — see What is Spend Data?.

🚧

Amounts are not in the same unit everywhere

Endpoint	Fields	Unit
Cards	availableBalance, spendingLimit, subscriptionBudget.*, request.amount	Major units — 375 is 375.00 EUR
Requests	requestedAmount	Smallest unit — 25000 is 250.00 EUR
Requests	minAmount, maxAmount filters	Major units, in the company's currency
Transactions	amountBilled, amountDeclared, fxFeeAmount	Smallest unit — 15000 is 150.00 EUR

1. Cards

▶️

Try it in Postman: 1.1 List active cards · 1.2 Read a card · 1.3 Why is it blocked? · 1.4 Where is the physical card?

Get Cards lists the company's cards, 30 per page, filtered by type (single_purchase, subscription, physical, multi_use), status, userId (the holder), or creation date (createdAfter, createdBefore, as YYYY-MM-DD):

curl -G https://public-api.spendesk.com/v1/cards \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  --data-urlencode "type=subscription" \
  --data-urlencode "status=Active"

The status filter is case-sensitive and takes the values the cards return — Active or Blocked, not active.

Each card carries:

Get a Card returns one card by ID.

• Why is a card blocked? Get a Card Blocking History lists every block, past and active, with its initiator (user, support, scheduledDeactivation, automatic, controlRule, internal); endedAt is null while it is active. A card can be blocked without a reason in either place — a single-purchase card after its payment, for example — so don't rely on them alone.
• Where is a physical card? Get a Card Order returns the shipping state (to_pickup, to_ship, shipped), tracking link and dates. It returns 404 when the card was never physically ordered.

2. Requests

▶️

Try it in Postman: 2.1 Requests waiting for approval · 2.2 Read a request

Get Requests lists spend requests, 30 per page, filtered by type, state (pending, approved, refused, cancelled…), requesterId, supplierId, creation date, or amount (minAmount, maxAmount, in major units). Add withApproval=true to see the approval chain:

curl -G https://public-api.spendesk.com/v1/requests \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  --data-urlencode "state=pending" \
  --data-urlencode "withApproval=true"

{
  "approval": {
    "isAutoApproved": false,
    "autoApprovalReason": null,
    "steps": [
      {
        "state": "current",
        "approvers": [{ "type": "user", "userId": "pmhsuj1ddcy562", "actingUserId": null, "isDelegated": false }],
        "decision": null
      }
    ]
  }
}

The step whose state is current is the one being waited on; its approvers are who has to act. Get Users turns their IDs into names. Each request also has an appUrl that opens it in Spendesk. Get a Request returns one request.

3. Card transactions

▶️

Try it in Postman: 3.1 Settled card payments · 3.2 The card's settled payments · 3.3 Declined card payments

Settled and declined payments come from two endpoints that do not work the same way:

Both filter by startDate, endDate (YYYY-MM-DD, end day included), userId and cardId:

curl -G https://public-api.spendesk.com/v1/transactions/successful \
  -H "Authorization: Bearer YOUR_ACCESS_TOKEN" \
  --data-urlencode "startDate=2026-08-01" \
  --data-urlencode "endDate=2026-08-31"

• For a full view of a period, call both endpoints and merge the results.
• Never add up amounts in different currencies: amountDeclared is in the merchant's currency, which varies from one payment to the next.
• Helping a cardholder with a declined payment: reason says why, remediation what to do next.
• The older GET /v1/transactions endpoint is deprecated: use the two above.

With an AI assistant

Connected through the Spendesk MCP server, an assistant can answer these questions for you:

How many spend requests are waiting for approval, how long have they been waiting, and who requested them?

Which card payments were declined last month, and why?

Good to know

• Cards and transactions are not the accounting record. For bookkeeping, use payables — see What is Spend Data? and Exporting accounting data.
• Check the unit of every amount — the table in How it fits together.
• Data may be cached for a short period: a payment or request made a moment ago may appear a little later.

Last checked against the Spendesk demo environment on 29 September 2026.