Skip to main content
With an access token in hand, you’re ready to hit the API. Every call goes to a single GraphQL endpoint — the token decides whose account you’re operating on.

​
The endpoint

There are no versioned REST paths and no per-capability base URLs. You send every query and mutation to the same address.

​
Confirm your token works

getMerchants is the cheapest way to prove your setup end to end. It reads nothing sensitive, moves no money, and needs only the LIST_OFFERS scope.
A working token returns the merchant:
That single response confirms four things at once: your endpoint is right, your token is valid, it carries the scope the query needs, and it is scoped to an account that can read the catalog.
An empty array is not an error. getMerchants filters by name, so a merchant that isn’t in the staging catalog returns [] with no errors block. If you get an empty result, try the query without a name argument to see what staging currently carries.

​
When it doesn’t work

The token was rejected before the query ran. Most often the credentials came from the wrong environment — staging and live have separate applications. See If the token request returns 401.
The token is valid but lacks the scope the operation needs. The message names it, for example getMerchants requires LIST_OFFERS. Mint a new token with that scope added — scopes are fixed at mint time and cannot be widened afterwards.
The query doesn’t match the schema — usually a field that doesn’t exist or a wrong argument shape. The response names the offending field. Check the operation in the API reference.

​
Where to next

Your first gift card purchase

Deposit funds, buy a gift card, and reveal its redemption details — the full happy path.

Create and spend with a virtual card

Pick a card program, issue a card with spend controls, and track its activity.

Idempotency

Money-moving mutations take an idempotencyKey. Read this before your first write.

API reference

Every query, mutation, and type.