Skip to main content
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. 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, 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 :
Fais un GET sur cette URL pour obtenir les métadonnées de la ressource protégée :
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.
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é.

​
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 :
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.

​
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.