API keys, scopes & quotas : les outils tranchants ont besoin d’étiquettes

Une API key est un outil de production. La traiter comme un mot de passe scotché sous un clavier, c’est ainsi que les intégrations deviennent des rapports d’incident. ReVend OS donne aux API keys leur propre surface de gestion, parce que les outils tranchants méritent des étiquettes. /settings/api est le hub — une carte pour les keys, une pour les webhooks, une pour la documentation et une pour l’usage — et /settings/api/keys est l’endroit où vivent les keys.

Scopes

Les keys utilisent des scopes : read, write et admin. Les endpoints déclarent le scope requis. Une intégration de reporting ne devrait pas recevoir des pouvoirs admin simplement parce qu’il était plus facile de cocher la plus grosse case. Une key peut aussi porter une date d’expiration, pour qu’une key créée pour un week-end de migration cesse de fonctionner le lundi sans que personne ait à penser à la révoquer.

Limites

Les responses incluent des headers de rate-limit et de quota mensuel. Le default par minute suit le package — 30 pour une organisation sandbox, 60 en starter, 120 en professional, 300 en enterprise — et peut être surchargé par key quand une intégration parle légitimement plus que les autres. Les limites à la minute empêchent une boucle bavarde de devenir un phénomène météo à l’échelle de la plateforme ; les quotas mensuels relient l’usage au package du tenant. L’usage apparaît sous /settings/api/usage, pour que les responsables d’intégration voient ce que leurs systèmes font réellement.

IP allowlists et données de dernière utilisation

Les keys peuvent porter des IP allowlists, et un appel venu de l’extérieur de la liste est refusé et journalisé comme refus d’IP. Une utilisation réussie enregistre l’heure de dernière utilisation, l’IP et le user agent. Quand quelque chose se met à appeler depuis un nouvel endroit, les admins ont des faits plutôt qu’une salle pleine de suppositions.

Rattachement au bidder

Une key qui place des bids doit dire de qui sont ces bids. Rattacher une key à un bidder principal n’est possible que pour des companies bidder vérifiées, premium et non blocklistées, pour qu’une key ne puisse pas prétendre représenter un buyer qu’elle n’a pas le droit de représenter. Les règles d’auction qui s’appliquent à l’humain s’appliquent au script.

Rotation

La création et la rotation d’une key montrent le token en clair une seule fois. La rotation émet un nouveau token et garde l’ancien valide pendant un chevauchement de sept jours, assez pour déployer la nouvelle key et retirer l’ancienne du système externe. Après quoi le secret n’est plus qu’un hash et un souvenir. Les actions de sécurité sur une key — création, rotation, révocation — écrivent des audit events consultables depuis la même page. C’est exactement le genre d’inconfort que la sécurité est censée produire.