Clés API et authentification

Chaque appel REST et chaque session MCP s’authentifie avec une clé API que vous créez dans l’application. Une clé agit en votre nom, dans la limite des autorisations que vous lui accordez. Il n’existe qu’un seul type de clé et un seul header, pour l’API REST comme pour le serveur MCP.

app.stickyprompts.com/settings#api 1 Créer une clé 2 Le seul header nécessaire 3 Renommer, restreindre, supprimer

Créer une clé

1. Ouvrir Settings > API keys

   Accédez à Settings et sélectionnez API keys.

2. Générer une clé

   Sélectionnez Generate key. Donnez-lui un nom qui indique où elle sera utilisée (par exemple Northwind CRM sync) et cochez les autorisations dont elle a besoin (voir la référence des autorisations).

3. Copier la clé

   La clé complète ne s’affiche qu’une seule fois, juste après sa création. Elle ne peut plus être récupérée ensuite, ni par vous ni par StickyPrompts. Enregistrez-la immédiatement dans votre gestionnaire de secrets.

Seul un utilisateur connecté à l’application peut créer des clés. Les endpoints de gestion des clés ne peuvent pas être appelés avec une clé API : une clé ne peut donc jamais créer, lister ni modifier de clés.

Format de la clé

STICKY-API-<64 characters>

• Le préfixe est toujours STICKY-API-, suivi de 64 caractères aléatoires. La clé complète compte 75 caractères.
• La partie aléatoire se compose de chiffres, de consonnes (aucune voyelle), de - et de _.
• StickyPrompts ne stocke qu’une empreinte (hash) du secret, ainsi que ses 16 premiers caractères pour le retrouver. C’est pourquoi une clé perdue ne peut plus être affichée.

Cycle de vie

Envoyer la clé

Envoyez la clé comme token bearer dans le header Authorization de chaque requête :

Authorization: Bearer STICKY-API-...

Le préfixe Bearer STICKY-API- est sensible à la casse et doit être reproduit à l’identique. Il n’existe aucune autre méthode, ni paramètre d’URL (query string) ni cookie.

curl https://api.stickyprompts.com/api/v1/workspace \
  -H "Authorization: Bearer $STICKY_API_KEY"

import os
import requests

r = requests.get(
    "https://api.stickyprompts.com/api/v1/workspace",
    headers={"Authorization": f"Bearer {os.environ['STICKY_API_KEY']}"},
)
print(r.status_code, r.json())

const res = await fetch("https://api.stickyprompts.com/api/v1/workspace", {
  headers: { Authorization: `Bearer ${process.env.STICKY_API_KEY}` },
});
console.log(res.status, await res.json());

(GET /workspace nécessite l’autorisation organization_get.)

Ce qu’une clé peut voir

Une clé agit en tant que l’utilisateur qui l’a créée. Elle voit exactement ce que voit cet utilisateur (son espace de travail, ses projets et tout ce qui a été partagé avec lui), et ses autorisations restreignent encore ce périmètre. Une clé ne peut pas être limitée à un espace de travail ou à un projet précis.

Si votre compte cesse d’être actif, vos clés cessent de fonctionner avec lui. Si vous quittez un espace de travail ou perdez l’accès à un projet, vos clés perdent cet accès elles aussi.

Comment une requête est vérifiée

Chaque requête passe par les contrôles suivants, dans cet ordre. Le premier qui échoue détermine la réponse.

Par ailleurs, les requêtes provenant d’une région que le service ne dessert pas sont refusées avec 403 {"error":"access from your region is not supported"}, en REST comme en MCP.

L’erreur d’autorisation nomme l’autorisation qui vous manque : en général, il suffit de modifier la clé et de la cocher.

{"error": "This api key does not have any of the required permissions. You need at least one of: prompts_get"}

Via MCP, l’étape 4 se déroule autrement : toute clé valide et active peut se connecter, et les outils pour lesquels la clé n’a pas d’autorisation sont simplement masqués. Voir Vue d’ensemble de MCP.

Routes inaccessibles aux clés

Certaines parties de l’API sont réservées à une personne connectée à l’application. Une clé API y reçoit 403, quelles que soient ses autorisations :

• Les routes de compte, de connexion et d’authentification.
• Les routes de facturation et d’abonnement.
• La gestion des clés API (création, liste, modification et suppression des clés).
• Les routes d’administration réservées aux équipes de StickyPrompts.
• Quelques routes enregistrées sans autorisation de clé API, par exemple la lecture d’un prompt GET /prompt/:id et le partage d’agents (GET /agents/:id/shares et les routes PATCH /agents/:id/share_with_*). Le partage des agents se fait dans l’application.

Protéger vos clés

• Côté serveur uniquement. Conservez les clés dans des variables d’environnement ou dans un gestionnaire de secrets. Ne les commitez jamais, ne les écrivez pas dans les logs et ne les collez pas dans des tickets ou des chats.
• Moindre privilège. Ne cochez que les autorisations dont l’intégration se sert. Un bot de reporting n’a pas besoin de integration_email_manage. Partez des ensembles suggérés.
• Une clé par intégration. Nommez chaque clé d’après le système qui l’utilise. Vous pourrez ainsi révoquer une intégration sans toucher aux autres, et vérifier à sa date de dernière utilisation si elle est toujours active.
• Rotation. Remplacez vos clés au rythme qui vous convient, et immédiatement lorsqu’une personne qui y avait accès s’en va ou qu’une clé a pu fuiter. Créez d’abord la nouvelle clé, basculez dessus, puis supprimez l’ancienne.
• Au nom de qui agit la clé. Une clé agit en votre nom. Pour une intégration partagée, envisagez de créer la clé depuis un compte dont les accès correspondent à ce que l’intégration doit voir.

Voir aussi