Tester votre intégration dans la sandbox de votre boutique
Créer des commandes fictives et vérifier leurs événements sans paiement ni fabrication réelle.
Publié par FRED
Chaque boutique FRED peut posséder une sandbox indépendante. Dans le dashboard, sélectionnez votre boutique puis Créer la sandbox. Choisissez un environnement vide, un produit de démonstration ou une copie de votre configuration avec les produits que vous sélectionnez. Les objets copiés reçoivent de nouveaux identifiants. La copie concerne les produits avec fichier importé et les réglages de nom, expéditeur et validation. Les inserts, éléments du catalogue partagé, contacts, paiements et connexions Shopify ne sont pas copiés. Les réglages de test ne sont pas synchronisés avec la production.
Connecter votre serveur
Ouvrez la sandbox puis Clés API et créez une clé de test. Elle commence par
sk_test_ et reste liée à cette sandbox. Utilisez la même URL d’API et les mêmes
routes métier qu’en production, avec X-API-Key. Le choix d’environnement dans
le dashboard ne change pas celui de votre application : sa clé détermine son accès.
Pour piloter les simulations, ajoutez sandbox:simulate aux permissions nécessaires
aux fichiers, devis et commandes. Gardez la clé sur votre serveur.
Les fichiers, produits, devis, commandes et webhooks de deux sandboxes restent séparés, même lorsque les boutiques appartiennent au même compte. Un identifiant obtenu en production ne peut pas être utilisé dans une sandbox.
Piloter une commande
Créez et confirmez une commande de test avec les routes habituelles. Une commande confirmée utilise un paiement fictif et une ferme simulée. Par défaut, son avancement est manuel : utilisez les Outils de test du dashboard ou l’API de simulation.
curl https://api.fredpod.com/v1/sandboxes/$FRED_SANDBOX_ID/simulations \
-H "X-API-Key: $FRED_TEST_KEY" \
-H "Idempotency-Key: simulation-expedition-001" \
-H "Content-Type: application/json" \
-d '{"order_id":"ord_exemple","action":"complete"}'| Action | Condition et effet |
|---|---|
next | Avance les jobs d’une commande confirmée d’une étape |
complete | Avance jusqu’à l’expédition simulée |
printing_failed | Simule un échec lorsque les jobs sont en impression |
delivered | Marque une commande expédiée comme livrée |
payment_failed | Simule un paiement refusé avant confirmation |
capacity_unavailable | Simule une absence de capacité avant le démarrage |
shipping_delayed | Émet un incident de retard pour une commande expédiée |
Réutilisez la même Idempotency-Key et le même contenu après une erreur réseau.
Le résultat contient un identifiant de simulation et la génération de sandbox.
La clé d’idempotence est obligatoire. Le résultat reste consultable pendant 24 heures sur
GET /v1/sandboxes/{sandbox_id}/simulations/{simulation_id}. Les transitions
incompatibles avec l’état de la commande sont refusées.
Les prix et délais de test sont fictifs. Ils ne constituent pas un engagement de
prix, de capacité ou de fabrication en production. Les comparaisons et devis
storefront utilisent des mesures fictives identifiées par estimate_source: sandbox ;
aucun fichier n’est envoyé à une imprimante.
AI Studio et les achats de crédits réels ne sont pas disponibles en sandbox.
Vérifier les webhooks
Configurez des destinations dans l’environnement sandbox. Les notifications sont
réellement envoyées à ces URL HTTPS et signées avec les secrets de ces endpoints.
Le payload indique mode: "test", sandbox_id et sandbox_generation pour les
sandboxes de boutique. Séparez leurs traitements de ceux de production.
Le test de connexion webhook vérifie votre récepteur ; une simulation de commande vérifie le parcours métier et ses événements. Consultez les tentatives, erreurs et réessais dans la page Webhooks. Utilisez un relais HTTPS pour un serveur local.
Réinitialiser et passer en production
La réinitialisation conserve les clés et destinations webhook, puis crée une nouvelle génération de données. Les anciens objets et jetons de téléversement ne sont plus utilisables. Un webhook déjà reçu ne peut pas être rappelé. La suppression révoque les clés ; une recréation obtient une nouvelle identité. Les fichiers privés archivés sont purgés après le délai configuré par FRED.
Des quotas limitent le stockage et la fréquence des simulations. Par défaut, le stockage est limité à 100 Mo par génération et à 500 Mo pour les comptes de test du même compte réel, y compris les fichiers archivés jusqu’à leur purge.
Pour la production, créez une clé live, préparez les ressources et webhooks de production, puis configurez les prérequis de commande et de paiement. Aucun objet de test n’est converti automatiquement en commande réelle. La connexion Shopify actuelle refuse les clés de test pour activer un service réel : testez votre intégration FRED séparément avant cette activation.
Les anciennes clés de test sans sandbox de boutique conservent leur environnement historique partagé au compte. Elles ne sont pas réaffectées automatiquement. Après la création d’une sandbox de boutique, les nouvelles clés de test du compte doivent préciser leur sandbox.