Passer au contenu principal
Deux vérifications s’appliquent à chaque appel, et les deux doivent réussir :
  1. Le membre derrière le jeton doit avoir l’autorisation, comme catalog.items.create. Les autorisations viennent du rôle du membre dans l’organisation.
  2. Le jeton doit avoir la portée, comme catalog:write. Les portées sont choisies quand la clé est créée ou quand un membre approuve une application OAuth.
Une clé avec catalog:write ne peut toujours pas créer d’articles si le rôle de son propriétaire ne le permet pas, et la clé d’un propriétaire limitée à inventory:read ne peut pas comptabiliser d’ajustements. Dans les deux cas, la réponse est un 403 avec le code forbidden. Chaque point de terminaison de la référence de l’API indique l’autorisation et la portée qu’il exige.

​
Portées

Les portées vont par paires, lecture et écriture, pour chaque section de l’application. La lecture couvre tout ce qui ne fait que consulter. L’écriture couvre tout ce qui change quelque chose. Une clé d’API peut aussi détenir *, qui regroupe toutes les portées; une application OAuth ne le peut pas. Ne donnez à une clé que les portées dont sa tâche a besoin. Une clé qui alimente un tableau de bord des stocks n’a besoin que de inventory:read.

​
Limites du forfait

Certaines fonctionnalités dépendent du forfait de l’organisation. Un appel à une fonctionnalité que le forfait n’inclut pas donne une réponse 403 avec le code plan_upgrade_required, et feature nomme ce qui manque. Rien n’est enregistré.