> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fluz.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Make your first API call

> Run an authenticated GraphQL request against staging and confirm your token works.

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

| Environment | Endpoint |
| - | - |
| Staging | `https://transactional-graph.staging.fluzapp.com/api/v1/graphql` |
| Live | `https://transactional-graph.fluzapp.com/api/v1/graphql` |

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.

```bash theme={null}
curl -X POST https://transactional-graph.staging.fluzapp.com/api/v1/graphql \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"query":"query { getMerchants(name: \"Burger King\") { name slug } }"}'
```

A working token returns the merchant:

```json theme={null}
{
  "data": {
    "getMerchants": [
      {
        "name": "Burger King",
        "slug": "burger-king"
      }
    ]
  }
}
```

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.

<Note>
  **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.
</Note>

## When it doesn't work

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    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](/get-started/api-credentials#if-the-token-request-returns-401).
  </Accordion>

  <Accordion title="AUTH-0031 Insufficient permissions">
    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.
  </Accordion>

  <Accordion title="GRAPHQL_VALIDATION_FAILED">
    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](/api-reference/overview).

    The same code comes back with HTTP `400` when a query exceeds the [query cost limits](/concepts/rate-limits). The message then reads `Query Cost limit of 7000 exceeded`; select fewer fields or split the query.
  </Accordion>
</AccordionGroup>

## Where to next

<CardGroup cols={2}>
  <Card title="Your first gift card purchase" icon="gift" href="/quickstart/first-gift-card">
    Deposit funds, buy a gift card, and reveal its redemption details — the full happy path.
  </Card>

  <Card title="Create and spend with a virtual card" icon="credit-card" href="/quickstart/create-and-spend-with-a-virtual-card">
    Pick a card program, issue a card with spend controls, and track its activity.
  </Card>

  <Card title="Idempotency" icon="shield-check" href="/concepts/idempotency">
    Money-moving mutations take an `idempotencyKey`. Read this before your first write.
  </Card>

  <Card title="API reference" icon="book" href="/api-reference/overview">
    Every query, mutation, and type.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.