Mode test

Chaque espace peut créer des clés de test, préfixées skoup_test_. Elles permettent de construire une intégration de bout en bout — lectures, écritures et webhooks — sans toucher à vos vraies données et sans déclencher le moindre sampling IA.

Ce que lit une clé de test

Les clés de test lisent un espace de démonstration partagé : une marque de vélos, Nordvelo, avec douze semaines de mesures réalistes sur plusieurs marchés, des alertes ouvertes, un backlog de correctifs, un catalogue et des commandes attribuées. Les données sont figées : vos tests sont reproductibles.

Chaque objet renvoyé en mode test porte "livemode": false.

Ce qui se passe à l’écriture

Les écritures passent par exactement la même validation qu’en live : mêmes champs obligatoires, mêmes quotas, mêmes transitions d’état, mêmes codes d’erreur. Vous recevez l’objet tel qu’il aurait été enregistré.

Puis tout est annulé. Rien n’est persisté, aucun e-mail ne part, aucun modèle IA n’est appelé et aucun traitement de fond ne tourne. Relire l’objet que vous venez de créer renvoie 404.

Les webhooks en mode test

Les endpoints de webhook ont eux aussi un mode. Les events produits par vos requêtes de test — un task.created après un POST …/tasks, par exemple — sont livrés à vos endpoints de test, avec "livemode": false. Un event live n’atteint jamais un endpoint de test, et inversement.

Vous pouvez aussi envoyer un exemple de n’importe quel type d’event depuis le dashboard : ouvrez un endpoint et cliquez sur Envoyer un event de test.

Passer en live

Une fois l’intégration au point, créez une clé live avec les mêmes scopes, créez des endpoints de webhook live, et remplacez les secrets. Rien d’autre ne change : URL, payloads et erreurs sont identiques dans les deux modes.