> For the complete documentation index, see [llms.txt](https://support.swisspay.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.swisspay.ai/api-reference/authentication.md).

# Authentication

Every SwissPay API request is authenticated with a bearer token.

## The Authorization header

```
Authorization: Bearer sk_test_...
```

Send this header on every request. No header, or an unknown key, returns:

```
HTTP/1.1 401 Unauthorized
{
  "error": {
    "code": "missing_api_key",
    "message": "Authorization header missing or invalid"
  }
}
```

## Where keys come from

* **Dashboard:** Developers → API keys.
* Click **Create key**, pick a scope, click **Create**.
* **You only see the plaintext key once** at creation. Copy it immediately into your secrets manager. If you lose it, revoke it and create a new one.

## Test and live keys

Both key types are used against the same base URL, `https://app.swisspay.ai` — the key's prefix decides the mode:

| Prefix        | Mode | Behaviour                                                                                                     |
| ------------- | ---- | ------------------------------------------------------------------------------------------------------------- |
| `sk_test_...` | Test | No real money moves. Use the [test cards](/api-reference/test-cards.md) to exercise every authorisation path. |
| `sk_live_...` | Live | Real cards, real settlement. Issued once your account is activated for live processing.                       |

Keys are mode-specific: a test key never touches live data, and a live key never accepts a test card. Keep them in separate secrets so you can't cross them by accident.

## Rotation

Best practice:

* Rotate keys at least every 90 days, and immediately on a known or suspected compromise.
* Roll forward: create the new key, deploy it, verify, then revoke the old key.
* Use a separate key per service / integration so you can revoke just one when needed.

## What to never do

* Never embed a key in client-side code (mobile apps, browser JavaScript).
* Never commit a key to a git repository.
* Never include a key in a support ticket — share the **key ID** instead.
* Never send a key in email or chat.

## Suspecting a leak

If you think a key has leaked:

1. Revoke it in the dashboard immediately.
2. Create a replacement.
3. Email <security@swisspay.ai> with the key ID, the suspected leak channel, and the rough timeline. Don't include the plaintext key.

We will review API access logs for the affected key.