qeda-logo

DocsGérer votre espace de travail

Accès API / tokens d'accès personnels

Settings → Developer Access : générer et scoper des tokens pour l'API de la plateforme Qeda — différent des API Keys de l'AI Hub.

Settings → Developer Access est pour les tokens qui s'authentifient auprès de l'API de la plateforme Qeda — gérer projets et déploiements de façon programmatique. C'est un token différent des API Keys de l'AI Hub (couvertes dans Sécuriser votre application), qui n'appellent que l'API AI ; les deux ne sont pas interchangeables.

La page Developer Access sans aucun token API encore
Un compte tout neuf en commence sans aucun — la même convention « rien tant que vous ne le créez pas » que les espaces de travail et les clés API ailleurs dans cette app.

Générer un token

La génération ne demande qu'un nom. Un nouveau token commence avec un accès Read-only — Write doit être activé après coup, pas choisi à la création.

La boîte de dialogue « Generate New Token » avec un champ Token Name
Pas de sélecteur de permissions ici — chaque nouveau token est Read-only par défaut.
La liste API Tokens montrant deux tokens avec des permissions différentes, des clés masquées, et des icônes d'action
Le même motif masqué par défaut que l'AI Hub : œil pour révéler, copier, un kebab pour les droits, et supprimer.

Scoper avec Read/Write

« Manage Rights », depuis le menu kebab d'un token, est le seul moyen d'ajouter l'accès Write après coup — deux cases à cocher, rien de plus granulaire pour l'instant (pas encore de scope par projet ou par endpoint).

La boîte de dialogue « Manage Rights » avec des cases Read et Write, toutes deux cochées
Un token Read-only ne peut ni déployer ni rien changer — Write est ce qui en fait un identifiant d'automatisation complet.

Remarque. Il n'y a pas encore d'API de plateforme contre laquelle ces tokens peuvent s'authentifier — en générer un produit une clé qui a l'air réelle mais sans backend derrière. Le modèle de scope ici (Read vs. Write, révocable à tout moment) est ce qui s'appliquera une fois cette API lancée, donc traitez un token Write comme vous traiteriez un mot de passe le jour où ce sera le cas : limitez son scope, et révoquez-le (icône corbeille) dès qu'il n'est plus utilisé.