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

# API keys

> Generate and manage the API keys that authenticate your integration with Paylead.

export const RequiredRoles = ({roles}) => <Note>
    <strong>Required Shift role:</strong> {roles}. See <a href="/program/shift/access-and-roles">Users management</a> for the full role matrix.
  </Note>;

<RequiredRoles roles="Technical" />

An API key is a bearer token that authenticates calls from a system outside [Shift](/glossary#shift), for example your bank's mobile app backend or your data ingestion job. Use one when a server on your side needs to read or write Paylead data on its own, with no human signed in to click anything. Generate, view, and revoke keys from **My account** > **Developers** > **API Keys**.

For how a credential becomes a bearer token and how that token travels on each call, see [Authentication](/program/user-journey/authentication). For events Paylead pushes to your system in real time, see [Webhooks](/program/shift/webhooks).

## Key types

The type you pick decides what the key is allowed to reach. It is fixed at generation: to change the reach of an integration, generate a new key of the right type and revoke the old one.

| Type | What a key of this type is for |
| - | - |
| **Program M2M** | Server-to-server access to your own [Program](/glossary#program) data: [Rewards](/glossary#reward), [Offers](/glossary#offer), [Brands](/glossary#brand), reporting, and [Ventilation](/glossary#ventilation) files. This is the type behind back-office integrations, data warehouse feeds, and scheduled reports. Shift preselects it. |
| **Connector** | Legacy. Feeds [Consumer](/glossary#consumer) and bank-connection data into Paylead. |
| **Injector** | Legacy. Pushes raw transactions into Paylead. |

Pick **Program M2M** unless Paylead asked you for one of the other two. When a Paylead contact asks you for a **Connector** or an **Injector** key, ask them for the matching integration contract at the same time.

## View existing keys

The **API Keys** table lists every key active on your Program. Revoking a key removes its row, so the table is your live inventory of what can reach your data.

| Column | Description |
| - | - |
| **Created** | The date the key was generated. |
| **Type** | The key's type. See [Key types](#key-types). |
| **API Key** | The generated token, truncated to fit the column. |
| **Description** | The free-form label you set when generating the key. |

Each row also carries an **API Documentation** link and a bin icon that revokes the key.

<Warning>
  The full token is shown once, in the dialog that opens right after you generate the key. Copy it then and store it in your secret manager. If you did not, revoke the key and generate a new one.
</Warning>

### The API Documentation link

**API Documentation** opens a screen inside Shift, not the Paylead documentation site. It embeds the raw OpenAPI reference for that row's key type, plus a selector for the other available specification versions. Open it from a key row when you need to confirm what a key of a given type is technically allowed to call.

For the current Platform API, which is what a new integration should build against, use the [API reference](/program/api/releases).

## Generate an API key

<Steps>
  <Step title="Open the generator">
    In **My account** > **Developers** > **API Keys**, click **Generate new API key**.
  </Step>

  <Step title="Select the type">
    **Type** is preset to **Program M2M**. Change it only if Paylead asked for a legacy type. One key serves one system: do not reuse a key across services.
  </Step>

  <Step title="Add a description">
    **Description** accepts 20 characters at most, so name the consuming system as tightly as you can, for example `Lyra mobile app` or `Yuna ingestion job`. Future operators rely on this label to know what they would break by revoking the key.
  </Step>

  <Step title="Confirm">
    Click **Confirm**. Shift issues the key and opens a dialog showing the **API Key** value.
  </Step>

  <Step title="Copy the token">
    Click **Copy Token**, paste the value into your secret manager, then click **Close**. The new key appears in the list.
  </Step>
</Steps>

<Check>
  The key is usable immediately, with no activation step. Send one authenticated call from the consuming system to confirm the token reached it intact.
</Check>

The key issued on this screen is a JWT: three Base64URL segments separated by dots (`header.payload.signature`), with no prefix. The Platform API client `client_secret` described on [Authentication](/program/user-journey/authentication) is a different credential, with a different shape and its own issuing flow.

## Rotation and revocation

A key generated here **does not expire**: it stays valid until someone revokes it, so rotation only happens if you schedule it. Treat API keys like any other production secret.

* **Store them in a secret manager** (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager). Never commit a token to Git, paste it in a ticket, or share it over chat.
* **Rotate periodically**: generate a new key, deploy it to the consuming system, confirm traffic flows on the new token, then revoke the old one from Shift.
* **Revoke immediately on suspicion**: if a token may have leaked, revoke it rather than waiting for evidence. A revoked key cannot be restored, and generating a replacement costs a minute.
* **One key per consuming system**: sharing a key across services means revoking it takes down all of them at once, and the **Description** no longer tells you which system you are about to break.

Sandbox and production are isolated environments with separate credentials, so generate each key from the matching Shift environment. A sandbox token reaches sandbox endpoints only, and a production token production endpoints only.

### Revoke a key

In the key's row, click the bin icon, then click **Confirm**. Shift revokes the key and the row leaves the table.

<Warning>
  Revocation is immediate and cannot be undone. Every system still presenting that token starts failing authentication at once, so deploy the replacement token before you revoke, not after.
</Warning>

## What's next

<CardGroup cols={2}>
  <Card title="Webhooks" icon="zap" href="/program/shift/webhooks">
    Register a callback URL and receive Program events in real time.
  </Card>

  <Card title="Authentication" icon="key" href="/program/user-journey/authentication">
    Token format, headers, and credential handling for the Platform API.
  </Card>
</CardGroup>