Authentification

Trois familles d'identifiants sont délivrées aux clients. Une quatrième existe, à usage interne : elle figure ici pour vous éviter de la chercher.

1. OAuth 2.1 avec PKCE : le chemin MCP

La voie principale par laquelle un client IA accède à une boutique. Il s'agit d'un parcours d'autorisation complet, pas d'une clé qu'on colle :

1. Le client découvre les métadonnées du serveur d'autorisation.
2. L'utilisateur arrive sur l'écran de consentement, à /oauth/authorize, et voit exactement quels scopes sont demandés.
3. Le client échange le code, lié par PKCE.
4. Le jeton d'accès est limité à un seul storeId et stocké sous forme hachée.

Utilisez ce chemin dès que le client sait le négocier. C'est le seul où l'utilisateur voit et approuve la liste des scopes, et le seul qui vous permette ensuite de restreindre une autorisation.

En mode OAuth, c'est le compte du porteur qui est vérifié à chaque appel, pas seulement le jeton. Le jeton encore valide d'un compte banni ou supprimé cesse de fonctionner.

2. bst_mcp_ : le jeton MCP statique

Pour une machine qui ne peut pas dérouler le parcours OAuth : une tâche de CI, une exécution sans navigateur. Claude Code et Cursor lisent un fichier de configuration et se connectent quand même en OAuth ; la clé est leur solution de repli, pas leur mode par défaut.

• Émise par boutique, depuis les réglages de la Custom App Shopify.
• Stockée sous forme de hash SHA-256 ; la valeur en clair n'est affichée qu'une fois et ne peut plus jamais être reconstituée.
• Détenir la clé vaut autorisation. Elle est limitée à la boutique : il n'y a donc pas de négociation de scope à part.

C'est la conséquence de ce dernier point qu'il faut bien comprendre : une clé statique satisfait la famille d'outils relay, c'est-à-dire les outils qui atteignent Shopify par le pont. Elle ne satisfait pas les outils qui protègent une ressource BoostEcom dont la permission dépend de l'appartenance à une organisation : en mode statique, il n'y a aucun utilisateur identifié à vérifier, et une permission invérifiable doit refuser plutôt que laisser passer. Voir Outils MCP et scopes.

3. bei_ : la clé Intelligence

Un jeton en lecture seule pour l'Intelligence API.

• Porte le scope read:intelligence, qui est désormais appliqué, et plus seulement enregistré.
• La limite de débit est comptée par clé, pas par adresse IP.
• Stockée sous forme de hash SHA-256.

Tout ce qui n'est pas exactement Bearer bei_<hex> est refusé net, et non rétrogradé en accès anonyme.

Voir Intelligence API.

4. bst_ : usage interne

Des jetons émis par un admin, porteurs de permissions roadmap.*, et utilisés par un serveur MCP interne consacré à la feuille de route. Jamais délivrés aux clients. Ils ne figurent ici que pour qu'un préfixe bst_ croisé dans un changelog ne vous lance pas à la recherche d'une clé que vous ne pouvez pas obtenir.

Retirée : la famille sk_

Si un ancien document mentionne des clés sk_ ou un endpoint de canal REST, sachez qu'ils n'existent plus. Ces clés vivaient dans une table propre à chaque processus : aucune requête ne pouvait donc en transporter une d'une instance à l'autre, et chaque route protégée répondait 401. La famille et l'endpoint /api/channels/api ont été supprimés plutôt que réparés.

Choisir