Trois familles d'identifiants sont délivrées aux clients. Une quatrième existe et est interne. Elle est listée ici pour que vous n'ayez pas à la chercher.
1. OAuth 2.1 avec PKCE : le chemin MCP
Le moyen principal pour un client IA d'atteindre une boutique. C'est un flux d'autorisation complet, pas une clé collée :
- Le client découvre les métadonnées du serveur d'autorisation.
- L'utilisateur arrive sur l'écran de consentement à
/oauth/authorizeet voit exactement quels scopes sont demandés. - Le client échange le code, lié par PKCE.
- Le token d'accès est cantonné à un seul
storeIdet stocké haché au repos.
Utilisez ce chemin dès que le client sait négocier. C'est le seul où l'utilisateur voit et approuve la liste des scopes, et le seul où vous pouvez ensuite restreindre un octroi.
En mode OAuth, le compte du bearer est vérifié à chaque appel, pas seulement le token. Un token vivant d'un compte banni ou supprimé cesse de fonctionner.
2. bst_mcp_ — le bearer MCP statique
Pour une machine qui ne peut pas exécuter le flux 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 repli, pas leur défaut.
- Émis par boutique, depuis les réglages du Custom App Shopify.
- Stocké en hash SHA-256 ; le texte en clair n'est montré qu'une fois et n'est jamais re-dérivable.
- Détenir la clé, c'est l'autorisation. Elle est cantonnée à la boutique, il n'y a donc pas de négociation de scope séparée.
La conséquence de ce dernier point est ce qu'il faut comprendre : une clé statique satisfait la famille d'outils relay, ceux qui atteignent Shopify via le pont. Elle ne satisfait pas les outils qui protègent une ressource BoostEcom dont la permission dépend d'une appartenance à une organisation, parce qu'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 & scopes.
3. bei_ — la clé Intelligence
Un token en lecture seule pour l'Intelligence API.
- Porte le scope
read:intelligence, désormais appliqué, pas simplement stocké. - Le plafond de débit est compté par clé, pas par adresse IP.
- Stocké en hash SHA-256.
Tout ce qui n'est pas un simple Bearer bei_<hex> est carrément refusé
plutôt que dégradé vers l'anonyme.
Voir Intelligence API.
4. bst_ — interne
Tokens émis par un admin, portant des permissions roadmap.*,
consommés par un serveur MCP roadmap interne. Jamais délivré aux
clients. Listé seulement pour que voir un préfixe bst_ dans un
changelog ne vous envoie pas chercher une clé que vous ne pouvez pas
obtenir.
Retiré : la famille sk_
Si vous trouvez une référence à des clés sk_ ou à un endpoint de canal
REST dans un ancien document, c'est retiré. Ces clés vivaient dans une
map locale au process, donc aucune requête ne portait jamais l'une
d'elles au-delà d'une instance 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
| Vous construisez | Utilisez |
|---|---|
| Un client MCP capable de faire de l'OAuth | OAuth 2.1 PKCE |
| Un client MCP sur une machine sans navigateur (CI, headless) | bst_mcp_ |
| Un script d'intelligence en lecture seule | bei_ |