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

# API keys

> Create, scope, and disable integration keys

An **integration key** lets code outside Pixio act on your account. Create one per place you use it, so you can disable that one without breaking the others.

## Creating a key

<Steps>
  <Step title="Open Integrations">
    Click **Integrations** in the sidebar.
  </Step>

  <Step title="Name it">
    Name the key after where it will be used — `Production`, `Local dev`, `Zapier`. The name is how you'll recognize it later.
  </Step>

  <Step title="Choose its reach">
    Select which areas the key may touch (below). Grant only what the integration needs.
  </Step>

  <Step title="Copy it">
    Copy the key immediately and store it somewhere safe. Treat it like a password.
  </Step>
</Steps>

## What a key can reach

Access is grouped, so you can hand out narrow keys:

| Scope                              | What it allows                                           |
| ---------------------------------- | -------------------------------------------------------- |
| **Media & workflows**              | Generate, upload, manage assets, and run saved workflows |
| **Creative projects**              | Author Boards, Canvas, Cinema, and Cam View scenes       |
| **Agent & editor projects**        | Persist agent workspaces and apply timeline operations   |
| **Characters, prompts & training** | Manage reusable context and inspect training progress    |

<Tip>
  A key that only needs to generate images doesn't need project or training access. Narrow scopes limit the damage if a key leaks.
</Tip>

## Using a key

Send it as a Bearer token:

```bash theme={null}
curl https://beta.pixio.myapps.ai/api/v1/models \
  -H "Authorization: Bearer YOUR_INTEGRATION_KEY"
```

Everything a key does is billed to the same credit balance and constrained by the same plan as your account in the app.

## Disabling and re-enabling

Keys are **disabled**, not deleted — so the record of what existed stays intact.

* **Disable key** stops it working immediately. Any integration using it starts failing on the next request.
* Disabled keys are hidden by default; toggle **Show disabled** to see them.
* A disabled key can be **enabled** again if you disabled it by mistake.

<Warning>
  If a key leaks, disable it first and ask questions after. A leaked key can spend every credit on your account.
</Warning>

## Good practice

* **One key per environment.** Never share a key between production and local development.
* **Server-side only.** A key in client-side JavaScript or a mobile app binary is a public key.
* **Environment variables**, never source control. Add your `.env` to `.gitignore`.
* **Rotate on staff change.** Create the replacement, switch over, then disable the old one — in that order, so nothing breaks mid-cutover.
* **Name honestly.** `test2` tells you nothing in six months.

## Troubleshooting

<AccordionGroup>
  <Accordion title="401 Unauthorized">
    The key is wrong, disabled, or missing from the header. Check the header is exactly `Authorization: Bearer <key>`, then confirm the key is still Active in **Integrations**.
  </Accordion>

  <Accordion title="403 Forbidden">
    The key is valid but lacks the scope for that operation. Check its scopes against the table above.
  </Accordion>

  <Accordion title="Insufficient credits">
    The account is out of credits — the same wall you'd hit in the app. Top up on [Billing](/credits).
  </Accordion>

  <Accordion title="A model works in the app but not through the API">
    Access is per plan, not per surface. If your plan can't run it in the UI, a key can't either.
  </Accordion>

  <Accordion title="Key creation is unavailable">
    Key storage isn't configured on that environment. This affects self-hosted or preview deployments, not the hosted app.
  </Accordion>
</AccordionGroup>