Testez les limites du cycle de vie avant la Production
Utilisez un projet Sandbox dédié, des références de commande synthétiques et des boîtes de réception que vous contrôlez. N’utilisez jamais de véritables contacts clients dans une recette. Conservez les identifiants et le corps exact de chaque requête pour pouvoir réessayer sans risque après une réponse incertaine.
| Scénario | Procédure | Preuve attendue |
|---|---|---|
| Première authentification | Jeu de données du démarrage rapide avec delivery:read | 200, résultat de test stable et identifiant de requête |
| Adresse acceptée | Créer une confirmation dont l’expiration est future ; ouvrir son URL destinataire et soumettre le lieu proposé | Instantané immuable confirmé |
| Adresse corrigée | Créer une autre demande ; choisir un autre lieu valide dans le parcours destinataire | Instantané corrigé ; proposition d’origine conservée |
| Annulation | Annuler une nouvelle demande en attente via l’API de confirmation d’adresse | Cancelled ; l’ancien lien destinataire ne permet plus de finaliser |
| Expiration | Créer une demande à courte durée, attendre au-delà de expiresAt, puis ouvrir son lien | Expirée/indisponible ; aucun instantané finalisé |
| Transit/dépôt/en cours de livraison | Envoyer les commandes de livraison documentées | Historique de référence ordonné des événements |
| Tentative échouée et RTS | Envoyer une résolution d’échec de livraison avec RecipientUnavailable et attemptCount: 3 | Un retour RTS ; une preuve répétée n’en crée pas d’autre |
| Livraison avec preuve | Configurer Signature/Photo, soumettre d’abord la preuve correspondante, puis CompleteDelivery avec son proofId | Delivered ; preuve absente ou incorrecte rejetée |
| Retour demandé par le destinataire | Lier une expédition Delivered avec un contact de test vérifié ; demander une collecte ou un dépôt | La demande de retour entre dans le parcours d’approbation documenté |
| Retour client de référence | Créer et approuver un retour client synthétique | Requested puis Approved ; historique de livraison initial inchangé |
| Preuves de collecte et de réception | Téléverser des PNG de signature synthétiques distincts pour la collecte et la réception | Chaque événement accepte uniquement la preuve qui lui correspond |
| Mauvaise portée | Émettre une clé en lecture seule ; tenter un événement | 403 ; aucune modification |
| Mauvais environnement | Lire une ressource Sandbox avec une clé d’un autre environnement | Ressource inaccessible |
| Événement en double | Rejouer exactement l’UUID et le corps conservés | Aucun second événement de référence |
| Événement hors ordre | Finaliser avant la remise requise | 409 ; examiner et corriger l’état plutôt que changer d’UUID |
| Nouvelle tentative de webhook | Le récepteur renvoie 503 avant l’enregistrement durable, puis se rétablit | Nouvelle tentative acceptée une seule fois |
| Webhook en double/rejeu | Rejouer une livraison synthétique acceptée | Même identifiant d’événement ; aucune action métier en double |
| Renouvellement du lien de collecte | Émettre un second lien de collecte non finalisée, puis essayer l’ancien | Ancien lien rejeté |
| Suspension des écritures de retour | Lorsque returns_paused est renvoyé, réessayer plus tard avec les mêmes identifiants | Écriture réussie après reprise du service ; lectures toujours disponibles |
Le point de terminaison de test en lecture seule accepte aussi fault=error-403, error-404, error-409, error-429 et error-500 pour tester le traitement des statuts. Ces erreurs simulent des réponses ; elles ne prouvent pas de véritables transitions de cycle de vie et ne modifient aucune donnée.