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

# Authentification

> Comment un client s'authentifie auprès du MCP marchand storekit : OAuth 2.1 avec discovery de ressource protégée et une connexion au dashboard storekit.

Le MCP marchand s'authentifie avec OAuth 2.1. Chaque appel d'outil est restreint au compte auquel le token se résout ; rien dans les arguments d'un outil ne peut changer cela.

| | OAuth (connexion) |
| - | - |
| En-tête | `Authorization: Bearer <token>` |
| Identité | Un utilisateur du dashboard storekit |
| Compte | Le premier compte de l'utilisateur |
| Prérequis | Un compte sur la liste d'attente beta : [demander l'accès](https://t09czsyu90l.typeform.com/to/G6rIJWNv) |

Une requête non authentifiée reçoit `401` avec un en-tête `WWW-Authenticate` (ci-dessous).

## OAuth

L'endpoint est une ressource protégée OAuth 2.1. Le serveur d'autorisation est hébergé par [Scalekit](https://www.scalekit.com), avec la connexion elle-même déléguée au dashboard storekit, si bien qu'un utilisateur se connecte avec ses identifiants storekit habituels.

**1. Discovery**

Un `POST /mcp` non authentifié renvoie :

```http theme={null}
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="OAuth", resource_metadata="https://mcp.storekit.com/.well-known/oauth-protected-resource"
```

Fais un `GET` sur cette URL pour obtenir les métadonnées de la ressource protégée :

```json theme={null}
{
  "resource": "https://mcp.storekit.com",
  "authorization_servers": ["https://storekit.eu.scalekit.com/resources/res_143363546435027719"],
  "bearer_methods_supported": ["header"],
  "scopes_supported": ["read"]
}
```

Les métadonnées propres au serveur d'autorisation se trouvent sur son chemin `/.well-known/oauth-authorization-server`, comme d'habitude. Les clients s'y enregistrent eux-mêmes ; il n'y a pas d'ID client ou de secret à configurer. Les clients qui prennent en charge la spécification d'autorisation MCP (Claude, ChatGPT, Cursor, VS Code, Claude Code) font tout cela sans configuration.

**2. Connexion**

Le serveur d'autorisation redirige l'utilisateur vers le dashboard storekit, qui affiche **Connecting your MCP client, please wait...** pendant qu'il confirme la demande de connexion avec l'API storekit, puis redirige vers le client. Un utilisateur qui n'est pas connecté au dashboard se connecte d'abord. Si l'utilisateur appartient à plusieurs comptes, le token se résout à son **premier** compte ; il n'y a pas de sélecteur de compte.

**3. Appels**

Envoie le token d'accès dans `Authorization: Bearer`. Le `sub` du token est l'utilisateur storekit ; sa claim `scope` est attachée à la requête sous `scopes` (par défaut `read`). Rafraîchis-le selon les directives de ta bibliothèque OAuth ; un token expiré reçoit un `401` et le client relance la discovery.

> [!NOTE]
>
> Les rôles utilisateur du dashboard et l'accès par établissement ne s'appliquent pas au MCP. Un token pour un utilisateur qui ne voit qu'un seul établissement dans le dashboard lit tous les établissements du compte, et peut appeler les deux outils d'écriture. Choisis en conséquence qui se connecte : voir [Permissions et confidentialité](/docs/fr/guides/ai/permissions-and-privacy).

## Vérifier l'endpoint

Un appel non authentifié suffit à confirmer que le serveur est joignable et à voir l'en-tête de discovery qu'un client suit :

```bash theme={null}
curl -si https://mcp.storekit.com/mcp \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

Attends-toi à `401 Unauthorized` avec l'en-tête `WWW-Authenticate` montré plus haut. Questions sur l'accès ou la beta : [mcp@storekit.com](mailto:mcp@storekit.com).

## Vérifications d'Origin et de Host

Les requêtes portant un en-tête `Origin` sont vérifiées contre la liste d'origines de navigateur autorisées par storekit lorsqu'elle est configurée, et rejetées avec `403` avant l'authentification si elles ne correspondent pas. Les requêtes sans en-tête `Origin` (tout client desktop, CLI et serveur) passent directement à l'authentification. L'en-tête `Host` doit correspondre au nom d'hôte public.

## Limite de débit

60 requêtes par minute glissante, par utilisateur (par IP avant authentification). Un dépassement renvoie HTTP `429` avec un en-tête `Retry-After`, en dehors de l'enveloppe MCP.


## Related topics

- [Délivrabilité des e-mails](/docs/fr/guides/notifications/email-deliverability.md)
- [Politique de sécurité](/docs/fr/privacy-security/security-policy.md)
- [TISSL](/docs/fr/guides/integrations/pos/tissl.md)
- [Zonal (Aztec)](/docs/fr/guides/integrations/pos/zonal.md)
- [Bancontact](/docs/fr/guides/payments/bancontact.md)


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