Authorization, schéma Bearer :
La clé porte le workspace
Une clé appartient à un et un seul espace de travail, et aucune route ne lit un identifiant de workspace depuis la requête. Le périmètre des données est donc entièrement déterminé par la clé présentée : il n’y a rien à passer, et rien à se tromper de passer. Conséquence pratique : pour lire deux workspaces, il faut deux clés.Format
Une clé commence parst_. Le reste est aléatoire et opaque : il n’encode ni
votre identité, ni une date d’expiration, et ne se décode pas.
Côté SpotTracker, seule une empreinte de la clé est conservée. La valeur
complète n’existe qu’au moment où elle vous est affichée, ce qui a deux
conséquences directes :
- Copiez-la tout de suite. Elle n’est plus consultable ensuite, y compris par le support.
- Une clé perdue ne se retrouve pas, elle se révoque et se recrée.
Où la ranger
L’API n’autorise pas les appels depuis un navigateur (pas d’en-têtes CORS permissifs) : une intégration front-end n’est pas seulement risquée, elle ne fonctionnera pas. Appelez l’API depuis votre serveur, votre outil d’ETL ou votre plateforme d’automatisation.Une clé par usage
Nommez chaque clé d’après ce qu’elle sert. Le jour où un prestataire termine sa mission, où un script est mis hors service, ou bien où une valeur a pu fuiter, vous révoquez exactement ce qu’il faut sans interrompre le reste.Rotation et révocation
La révocation est immédiate : la clé cesse d’être acceptée au prochain appel, sans délai de propagation. Pour remplacer une clé sans coupure :1
Créer la nouvelle clé
Les deux clés coexistent, toutes deux valides.
2
Basculer les appelants
Déployez la nouvelle valeur partout où l’ancienne était utilisée.
3
Révoquer l'ancienne
Une fois qu’aucun appelant ne l’utilise plus. Le panneau des clés affiche
la date de dernière utilisation, ce qui permet de vérifier avant de
couper.
Conditions d'accès
Quelles offres ouvrent l’API, et ce qui se passe en cas de changement
d’offre.