Bac à sable

Une clé de test fonctionne dans le bac à sable. Vos requêtes passent par la même passerelle qu'avec une clé réelle : la clé, les scopes, les limites de débit, Idempotency-Key, les contrôles des requêtes, les tâches, les fichiers et les webhooks fonctionnent tous comme en production. Seul le travail lui-même est simulé : aucun outil ne s'exécute, rien n'est créé et rien n'est facturé.

Obtenir une clé de test

Dans l'espace personnel, ouvrez API → Clés, choisissez le type de clé Test et créez la clé. Une clé de test commence par gsk_test. Utilisez-la exactement comme une clé réelle.

Chaque réponse du bac à sable porte l'en-tête Grem-Sandbox: true, afin qu'un journal de test ne soit jamais pris pour du vrai travail - y compris les réponses produites avant la vérification de la clé (JSON mal formé, 413, chemin inconnu).

Ce qui se passe

• Les contrôles des requêtes sont réels. Une requête que la production refuserait est refusée dans le bac à sable avec le même statut et la même raison : un champ manquant, moins de 4 photos dans un pack de contenu, des textes sans bien, sans description, sans ville et sans surface. Les champs de formulaire des requêtes multipart, les champs de rapport d'une autre catégorie et les valeurs heatingType pour une maison sont aussi contrôlés, de même que les fichiers envoyés : leur type et leur taille. Ce que la production tronque ou remplace (un texte trop long, une valeur length de vidéo inconnue), le bac à sable l'accepte aussi.
• Les résultats sont des exemples. Les outils synchrones répondent immédiatement avec des valeurs d'exemple fixes. Les outils asynchrones renvoient un jobId ; la tâche passe de pending à running puis à son résultat en 5 secondes environ.
• La vérification de rapport d'expertise s'arrête à action_required avec des données extracted d'exemple, comme en production ; confirmez-la avec POST /valuation/review/jobs/{id}/confirm.
• Les fichiers sont des substituts. Les PDF et les images sont de vrais fichiers que vous pouvez ouvrir ; la vidéo, le docx et les textes sont de courts substituts étiquetés, avec le bon type de contenu. Un fichier n'existe que pour une tâche du bac à sable terminée, au chemin propre à cet outil et avec un identifiant d'artefact renvoyé par la tâche - sinon 404. Une vidéo d'avatar est servie pour n'importe quel identifiant d'artefact d'une tâche terminée, comme en production. Range fonctionne (206, 416).
• Les webhooks sont réels. Une clé de test crée et gère uniquement des points de terminaison webhook du bac à sable. Ils ne reçoivent que les événements des tâches du bac à sable - des envois signés avec nouvelles tentatives, exactement comme en production. Les points de terminaison réels ne reçoivent jamais d'événements du bac à sable, et une clé de test ne peut ni les voir ni les modifier.

Choisir le résultat

L'en-tête Grem-Simulate détermine comment se termine l'appel ou la tâche :

La valeur ne tient pas compte de la casse. Une valeur inconnue renvoie 400, ainsi une faute de frappe ne passe jamais pour un succès. Les clés réelles ignorent cet en-tête.

curl -X POST https://developers.grem.capital/api/v1/text/generate \
  -H "Authorization: Bearer gsk_test_xxx" \
  -H "Content-Type: application/json" \
  -H "Grem-Simulate: failed" \
  -d '{"city":"Berlin","totalArea":64}'

Ce que peut faire une clé de test

Différences avec la production

• Les résultats sont des exemples fixes, ni une estimation ni de vrais textes. Ne les montrez pas à vos utilisateurs.
• Le bac à sable ne vérifie pas que le bien indiqué dans objectId existe ou vous appartient ; dans ce cas, la production répond 403 ou 404.
• Les tâches et les résultats sont conservés pendant un jour.

Voir aussi

• Démarrage rapide
• Tâches et résultats
• Webhooks