Clés de provisioning
Une clé de provisioning permet à votre backend de créer et de gérer des clés d'API d'inférence par programmation — sans que personne ne se connecte à la Console. Idéal pour les produits SaaS qui émettent une clé par client final, par appareil ou par job CI.
Une clé de provisioning peut créer, modifier et supprimer n'importe quelle clé d'inférence de son workspace. Traitez-la comme un identifiant admin : stockez-la uniquement côté serveur et ne l'envoyez jamais aux navigateurs ou clients mobiles.
Fonctionnement
- Un owner ou un admin crée une clé de provisioning dans Console → Clés de provisioning. Elle porte le préfixe
sk-syn-prov-. - Votre backend appelle les
/api/provisioning/*endpoints avec cette clé pour créer des clés d'inférence (préfixesk-syn-). - Chaque clé d'inférence est limitée au même workspace et peut porter un plafond de dépense en USD et des
metadataopaques. - Remettez les clés d'inférence à vos clients. Révoquez-en n'importe laquelle individuellement à tout moment — la suppression d'une clé de provisioning n' n' affecte pas les clés d'inférence qu'elle a déjà créées.
Les clés de provisioning elles-mêmes sont créées uniquement dans la Console — il n'existe pas d'API pour générer une clé de provisioning. Ouvrez Console → Clés de provisioning (owner / admin uniquement).
Authentification
Passez la clé de provisioning comme Bearer token. Elle fonctionne uniquement sur /api/provisioning/* — une clé de provisioning ne peut pas effectuer d'appels d'inférence, et une clé d'inférence normale ne peut pas appeler ces endpoints de gestion (les deux renvoient 401 wrong_key_kind).
Authorization: Bearer sk-syn-prov-... Créer une clé d'inférence
POST /api/provisioning/keys
| Paramètre | Type | Description |
|---|---|---|
name | string | Libellé lisible pour la clé (par ex. "Device abc-123"). |
quota | number | Plafond de dépense en USD. Omettez ou définissez 0 pour illimité. |
allowed_models | string | Liste blanche de modèles séparés par des virgules (par ex. "claude-haiku-4-5"). Vide = tous les modèles auxquels le workspace a accès. |
ip_whitelist | string | Liste blanche IP / CIDR séparés par des virgules pour les requêtes effectuées avec cette clé. Vide = aucune restriction. |
expires_at | string | Horodatage d'expiration RFC3339 optionnel. Omettez pour aucune expiration. |
include_byok_in_limit | boolean | Si true, les appels BYOK comptent dans le quota de cette clé au prix catalogue upstream. Par défaut false. |
metadata | object | Tags JSON opaques que vous définissez (par ex. {"tenant_id":"acme"}). Stockés tels quels, max 8 Ko. Utilisés uniquement pour le listage / filtrage — n'affectent jamais l'authentification. |
curl https://synthorai.io/api/provisioning/keys \
-H "Authorization: Bearer sk-syn-prov-..." \
-H "Content-Type: application/json" \
-d '{
"name": "Device abc-123",
"quota": 5.0,
"allowed_models": "claude-haiku-4-5",
"metadata": { "tenant_id": "acme", "device_id": "abc-123" }
}'import requests
resp = requests.post(
"https://synthorai.io/api/provisioning/keys",
headers={"Authorization": "Bearer sk-syn-prov-..."},
json={
"name": "Device abc-123",
"quota": 5.0,
"allowed_models": "claude-haiku-4-5",
"metadata": {"tenant_id": "acme", "device_id": "abc-123"},
},
)
inference_key = resp.json()["key"] # full key — shown only onceLa réponse renvoie la clé complète dans le key champ exactement une fois. Stockez-la immédiatement — elle ne peut pas être récupérée ultérieurement.
{
"id": 42,
"key": "sk-syn-d4f0...e91b",
"key_prefix": "sk-syn-d4f0...",
"name": "Device abc-123",
"kind": "inference",
"created_via": "provisioning_api",
"parent_provisioning_id": 7,
"workspace_id": 11,
"quota_usd": 5.0,
"unlimited_quota": false,
"allowed_models": "claude-haiku-4-5",
"metadata": { "tenant_id": "acme", "device_id": "abc-123" },
"created_at": "2026-06-01T12:00:00Z"
} Lister les clés d'inférence
GET /api/provisioning/keys
Liste toutes les clés d'inférence du workspace. Filtrez par n'importe quel champ de métadonnées avec ?metadata.<key>=<value>; plusieurs filtres sont combinés avec AND.
# all keys
curl https://synthorai.io/api/provisioning/keys \
-H "Authorization: Bearer sk-syn-prov-..."
# only keys tagged tenant_id=acme
curl "https://synthorai.io/api/provisioning/keys?metadata.tenant_id=acme" \
-H "Authorization: Bearer sk-syn-prov-..." Récupérer, mettre à jour & supprimer
Adressez une clé d'inférence unique par son id :
- GET
/api/provisioning/keys/{id}— récupérer une clé. - PATCH
/api/provisioning/keys/{id}— mettre à journame,quota,status,allowed_models,ip_whitelist,expires_at,include_byok_in_limit, oumetadata. Les champskindet de lignée ne peuvent pas être modifiés. - DELETE
/api/provisioning/keys/{id}— révoquer une clé. Effet immédiat.
# disable a key (status 2 = disabled)
curl -X PATCH https://synthorai.io/api/provisioning/keys/42 \
-H "Authorization: Bearer sk-syn-prov-..." \
-H "Content-Type: application/json" \
-d '{ "status": 2 }'
# delete a key
curl -X DELETE https://synthorai.io/api/provisioning/keys/42 \
-H "Authorization: Bearer sk-syn-prov-..." Quotas & contrôle des dépenses
quota est un plafond en USD par clé d'inférence. L'usage est mesuré après chaque requête, donc une clé peut légèrement dépasser son plafond dans une courte fenêtre de règlement en cas de forte concurrence — dimensionnez les plafonds avec une petite marge pour les modèles de grande valeur. Lisez la dépense actuelle d'une clé depuis used_usd dans les réponses de liste / récupération.
Taguez les clés à la création avec metadata (tenant, appareil, environnement) afin de pouvoir les lister, les auditer et les révoquer en masse ultérieurement par filtre. Les clés créées de cette façon apparaissent aussi dans Console → Clés d'API avec un badge Programmatique et leurs tags.
Vous dimensionnez des plafonds en USD par clé ? Le LLM API cost calculator convertit le volume de tokens attendu d'un client en une dépense mensuelle que vous pouvez définir comme quota.