Environnements de test (sandbox)

Isolez votre développement, expérimentez sans crainte et effacez vos données en un seul clic.

Pourquoi utiliser des environnements de test ?

Lorsque vous intégrez des API financières, il est essentiel de tester la logique de votre application sans générer de transactions réelles ni envoyer d’e-mails à de vrais clients. Cord répond à ce besoin en vous fournissant un environnement de test (sandbox) entièrement isolé.

Les données créées en mode test (devis, clients, webhooks) n’interagissent jamais avec vos données live.

Identifier le mode test

Dans le tableau de bord : lorsque le mode test est actif, un indicateur visuel orange apparaît dans l’interface. Toutes les actions manuelles que vous effectuez ont lieu dans l’environnement isolé.
Dans l’API : vos clés API secrètes déterminent automatiquement l’environnement que vous appelez. Une clé de test interagit avec l’environnement de test, tandis qu’une clé live touche vos données réelles.

Important : n’utilisez jamais de clés réelles dans vos suites de tests unitaires ou d’intégration.

Réinitialisation rapide de l’environnement de test

Pendant le développement d’une intégration, vous générerez souvent des milliers d’enregistrements inutiles. Cord dispose d’un outil radical pour remettre votre environnement à zéro : l’endpoint de réinitialisation.

Vider les données de l’environnement de test

Vous pouvez déclencher un nettoyage destructif (qui supprime en cascade les clients, les devis, les produits et les événements de l’environnement de test) en envoyant un POST à l’endpoint interne suivant (une session active dans le navigateur en mode test est requise) :

POST /api/test-mode/reset

Attention : Cet endpoint comporte des protections strictes au niveau de la base de données (sandbox_of is not null). Même si vous l’appelez par erreur dans votre environnement live, la base de données annule la transaction pour protéger vos données réelles. Il ne fonctionne que dans les environnements sandbox.

Simulateurs (test helpers)

Avec une clé sk_test_, vous pouvez déclencher ce qu’un tiers fait en production : le SAT qui répond, le temps qui passe ou le client qui ouvre le lien. Chaque simulateur exécute le même code qu’en production : les webhooks, l’historique et les e-mails sortent exactement comme en live. Avec une clé live, ils répondent test_mode_only, et la base de données rejette toute simulation sur une organisation réelle.

Forcer le résultat du prochain timbrage

curl -X POST https://cordhq.app/api/v1/test_helpers/fiscal \
  -H "Authorization: Bearer sk_test_..." -H "Content-Type: application/json" \
  -d '{ "siguiente_resultado": "pac_caido" }'

Résultats : exito, pac_caido (la facture reste en brouillon et peut être relancée), receptor_invalido, certificado_vencido et timbre_duplicado. Le résultat est consommé par l’émission suivante ; s’il n’y en a aucun en attente, l’émission simulée réussit.

Simuler le client et le passage du temps

curl -X POST https://cordhq.app/api/v1/test_helpers/cotizaciones/8b0c6f0e-2d55-4c1e-9a43-6a2f1c7d9e10 \
  -H "Authorization: Bearer sk_test_..." -H "Content-Type: application/json" \
  -d '{ "accion": "vista" }'

vista enregistre l’ouverture par le client (quote.viewed) et vencer le fait expirer (quote.expired). Approuver, refuser et marquer comme payé se trouvent déjà dans POST /api/v1/cotizaciones/{id}.

Déclencher un webhook

curl -X POST https://cordhq.app/api/v1/test_helpers/webhooks \
  -H "Authorization: Bearer sk_test_..." -H "Content-Type: application/json" \
  -d '{ "evento": "quote.approved", "objeto_id": "8b0c6f0e-2d55-4c1e-9a43-6a2f1c7d9e10" }'

Accepte n’importe quel événement du catalogue. Avec l’objeto_id d’un devis ou d’une facture de test, il utilise ses données réelles ; sans lui, des données d’exemple avec des ids test_…. L’objeto_id doit correspondre au type de l’événement : un devis pour quote.*, payment.*, invoice.stamped et invoice.issued, et une facture pour les autres événements invoice.*. Les événements de clients, produits, tâches, promesses, litiges, remboursements, versements et compte utilisent toujours des données d’exemple. L’envoi passe par l’outbox réelle : signature, nouvelles tentatives et historique dans les envois de l’endpoint, dans l’onglet Webhooks du Cord Workbench. Avec objeto_id, l’événement apparaît aussi dans l’historique des événements et dans l’onglet Événements ; avec des données d’exemple, non, car ce n’est pas un événement de votre entreprise.