Authentification API
Comment s'authentifier sur l'API REST publique : cookies de session pour le tableau de bord, cles API en Bearer pour l'acces programmatique.
Il y a deux manieres de parler a Le Bureau. Le tableau de bord utilise un cookie de session pose a la connexion. Tout le reste -- scripts, jobs CI, integrations tierces, clients MCP -- utilise une cle API envoyee dans Authorization: Bearer sk_live_.... Chacune a son usage, elles ne sont pas interchangeables.
Cookies de session (tableau de bord uniquement)
Connectez-vous via Google ou GitHub et le tableau de bord recoit automatiquement un cookie de session securise. Le cookie est httpOnly, limite au domaine Le Bureau, et inaccessible depuis JavaScript. Il existe pour que le tableau de bord puisse appeler l'API sans gerer de jeton.
N'essayez pas de reutiliser ce cookie depuis un script, un job CI ou un worker. Il est lie a une session navigateur et n'est pas concu pour l'acces programmatique. Pour tout ce qui sort du tableau de bord, creez une cle API.
Cles API (acces programmatique)
Envoyez la cle comme jeton Bearer dans l'en-tete Authorization a chaque requete :
curl https://lebureau.talentai.fr/v1/desktops \
-H "Authorization: Bearer sk_live_..."
Les cles se gerent uniquement depuis le tableau de bord, sur /settings?tab=apiKeys -- il n'y a pas d'API pour creer, lister ou revoquer une cle avec une autre cle. Chaque cle commence par sk_live_, est hashee au repos, et n'est affichee en clair qu'une seule fois a la creation. Chaque cle porte une liste explicite de capacites qui decide quelles routes elle peut appeler. Voir Capacites API pour la liste complete et comment les choisir.
Limitation de debit
L'API publique autorise 60 requetes par minute et par cle. Les compteurs sont tenus par cle, pas par IP, donc deux cles distinctes utilisees en parallele disposent chacune de leurs 60/min. Si une integration a besoin de plus de marge, repartissez la charge sur plusieurs cles.
Quand la limite est atteinte, la reponse est 429 Too Many Requests. Si l'en-tete Retry-After est present, attendez ce nombre de secondes avant de reessayer. Sinon, attendez au moins quelques secondes avant l'appel suivant.
Erreurs d'authentification
| Statut | Signification |
|---|---|
401 Unauthorized | L'en-tete Authorization est absent ou mal forme, ou la cle est invalide ou revoquee |
403 Forbidden | La cle est valide mais ne porte pas la capacite requise par la route. Le corps contient required et held -- voir Capacites API |
429 Too Many Requests | Limite de debit atteinte. Respectez Retry-After s'il est present |
Pratiques de securite
- Ne committez jamais une cle dans git, ne la collez pas dans un ticket, ne l'embarquez pas dans du code cote client.
- Faites tourner les cles regulierement : creez la nouvelle, basculez l'integration, puis revoquez l'ancienne.
- Une cle par integration, pour qu'une revocation n'en casse pas d'autres.
- Restreignez chaque cle au minimum de capacites dont l'integration a vraiment besoin.