Quand vous créez une clé d'API de compte dans Provedly, vous prenez une seule décision : Read only ou Read and write. C'est un petit choix qui détermine ce qu'un assistant IA ou un script peut faire avec votre compte, et il vaut mieux le faire correctement dès le premier jour plutôt qu'après une mauvaise surprise.
Ce que permet chaque niveau
| Action | Lecture seule | Lecture et écriture |
|---|---|---|
| Voir le plan, les limites et la consommation | Oui | Oui |
| Lister les sites, widgets et barres | Oui | Oui |
| Lire les statistiques (impressions, clics, commandes) | Oui | Oui |
| Obtenir le snippet d'installation | Oui | Oui |
| Mettre en pause ou réactiver un widget | Non | Oui |
| Créer une barre, la modifier, la mettre en pause ou la réactiver | Non | Oui |
| Ajouter un enregistrement | Non | Oui |
| Marquer un enregistrement comme vérifié | Non | Non |
La dernière ligne n'est pas une coquille. Aucune clé ne peut marquer quoi que ce soit comme vérifié, quel que soit son niveau. La vérification ne provient que des webhooks signés de Stripe, Shopify et WooCommerce, et l'API n'offre aucun moyen de contourner cela. Les enregistrements ajoutés avec une clé d'écriture conservent la source API, portent une étiquette visible « Imported » dans le widget et n'affichent jamais la marque Vérifié. Pourquoi votre assistant ne peut pas vérifier un achat explique le raisonnement.
Le même tableau s'applique que la clé soit utilisée via l'API REST ou via le serveur MCP. Un appel d'outil est un appel d'API avec une façade plus conviviale.
Laquelle choisir
Une règle simple : donnez à une clé le strict nécessaire pour sa tâche, et créez une seconde clé quand une seconde tâche apparaît.
Rapports et questions. Un bilan hebdomadaire des statistiques, un script de tableau de bord, un assistant à qui vous demandez « comment s'est passée la semaine dernière » : lecture seule. Aucune de ces tâches n'a besoin de modifier quoi que ce soit, et une clé en lecture seule divulguée permet à un inconnu de lire vos chiffres, mais pas de toucher à votre site.
Mener des campagnes depuis un chat. Si vous voulez dire « mets en pause la barre Black Friday » ou « crée le compte à rebours de lancement » et que cela se produise, l'assistant a besoin de la lecture et de l'écriture. C'est tout l'intérêt du workflow Black Friday depuis un chat.
Backends qui ajoutent des achats. Un serveur qui envoie des enregistrements a besoin de la lecture et de l'écriture. Donnez-lui sa propre clé, nommée d'après le service, pour pouvoir la renouveler sans toucher au reste.
Prestataires et agences. Une clé par personne, portant son nom. À la fin de la mission, révoquez-la. Le côté agence est traité dans gérer de nombreux sites clients.
Les garde-fous valables quelle que soit la clé
Même une clé en lecture et écriture fonctionne dans les mêmes règles que le tableau de bord, ce qui limite les dégâts en cas d'erreur.
- Les limites du plan s'appliquent. Réactiver un widget ou activer une barre au-delà de la limite de votre plan est refusé.
- Les nouvelles barres démarrent en pause. Une barre créée via l'API ou le MCP n'est pas montrée aux visiteurs tant que quelqu'un ne l'a pas activée lors d'une seconde étape. Un prompt mal compris ou un script bogué produit un brouillon en pause, pas une bannière en ligne.
- Rien ne devient vérifié. Voir plus haut.
- La révocation est immédiate. Révoquez une clé dans Settings et la requête suivante qui l'utilise échoue.
Gérer les clés
Les clés commencent par provedly_ et ne sont affichées qu'une fois, à leur création. Provedly ne les affiche plus ensuite, il n'y a donc rien à récupérer : une clé perdue est révoquée et remplacée.
C'est l'endroit où les clés finissent qui cause la plupart des problèmes. Quelques endroits à surveiller :
Les fichiers de configuration des clients MCP. Claude Code et Cursor conservent les réglages des serveurs dans des fichiers de configuration. Si vous ajoutez le serveur au niveau du projet et que le projet est dans git, vérifiez avant de commiter. Le guide Claude Code et le guide Cursor indiquent tous deux où la clé est stockée.
L'historique du shell. Placez la clé dans une variable d'environnement ou un gestionnaire de secrets plutôt que de la coller dans une commande curl que vous retrouverez plus tard dans l'historique.
Le code côté navigateur. Une clé dans du JavaScript côté client est publique. L'API est destinée aux serveurs, aux terminaux et aux outils d'IA, jamais à un script exécuté sur votre boutique. Le script du widget lui-même n'a pas besoin de clé.
Les transcriptions de chat. Ne collez pas la clé dans la conversation avec votre assistant. Elle va dans l'en-tête Authorization de la configuration du serveur, où le client l'envoie sans que le modèle ait besoin de la voir.
Si une clé fuite
Révoquez-la dans Settings, puis créez-en une nouvelle et mettez à jour tous les endroits où l'ancienne était utilisée. Regardez ensuite ce qui a changé : la liste de vos barres et widgets montre l'état actuel, et tout enregistrement ajouté via l'API affiche la source API dans l'onglet Data du widget, ce qui les rend faciles à repérer et à supprimer. Comme les enregistrements API ne peuvent jamais être vérifiés, une clé divulguée ne peut pas placer de faux achats vérifiés sur votre page de vérification.
Questions fréquentes
Puis-je faire passer une clé de lecture seule à lecture et écriture ?
Créez une nouvelle clé avec le niveau voulu et révoquez l'ancienne. Garder un niveau fixe par clé rend évident ce que chacune peut faire.
Plusieurs outils doivent-ils partager une même clé ?
Cela fonctionne, mais des clés séparées sont plus simples au quotidien. Avec une clé par outil ou par personne, l'écran des clés d'API vous dit qui a accès, et en révoquer une ne casse pas les autres.
Le widget de mon site utilise-t-il l'une de ces clés ?
Non. La balise de script de vos pages utilise un token de widget public et n'a besoin d'aucun secret. Les clés d'API de compte servent uniquement à l'API REST et au serveur MCP.
Les clés sont disponibles sur tous les plans, Free compris. Créez un compte pour générer la première.