Test lifecycle boundaries before Production
Use a dedicated Sandbox project, synthetic order references and inboxes you control. Never use real customer contact data in a recipe. Keep IDs and the exact request payload from each step so an uncertain response can be retried safely.
| Scenario | Procedure | Expected evidence |
|---|---|---|
| First authentication | Quickstart fixture with delivery:read | 200, stable fixture result and request ID |
| Address accepted | Create a future-expiring confirmation; open its recipient URL and submit the proposed location | Confirmed immutable snapshot |
| Address corrected | Create another request; choose another valid location through the recipient flow | Corrected snapshot; original proposal retained |
| Cancellation | Cancel a fresh pending request through the address-confirmation API | Cancelled; old recipient capability cannot complete |
| Expiry | Create a short-lived request, wait past expiresAt, then open its link | Expired/unavailable; no completed snapshot |
| Transit/depot/out for delivery | Submit the documented delivery commands | Ordered canonical event history |
| Failed attempt and RTS | Submit a failed-delivery resolution with RecipientUnavailable and attemptCount: 3 | One RTS return; duplicate evidence does not create another |
| Delivered with proof | Configure Signature/Photo, submit matching proof first, then CompleteDelivery with its proofId | Delivered; omitted/wrong proof rejected |
| Recipient return | Link a Delivered shipment with verified test contact; request pickup or drop-off | Return request enters its documented approval flow |
| Canonical customer return | Create and approve a synthetic customer return | Requested then Approved; original outbound history unchanged |
| Pickup and receipt proof | Upload separate synthetic signature PNGs for pickup and receipt | Each event accepts only its corresponding proof |
| Wrong scope | Issue read-only key; attempt an event | 403; no mutation |
| Wrong environment | Read Sandbox resource with a separate environment key | Resource inaccessible |
| Duplicate event | Replay exact stored event UUID and payload | No second canonical event |
| Out-of-order event | Complete before required handover | 409; inspect/correct state rather than changing UUID |
| Webhook retry | Receiver returns 503 before durable commit, then recovers | Retry accepted once |
| Webhook duplicate/replay | Replay an accepted synthetic delivery | Same event ID; no duplicate business action |
| Pickup capability rotation | Issue a second uncompleted pickup link and try the old one | Old capability rejected |
| Return write pause | When returns_paused is returned, retry later with the same IDs | Write succeeds after service resumes; reads remain available |
The read-only fixture endpoint also accepts fault=error-403, error-404,
error-409, error-429 and error-500 to exercise status handling. These faults
simulate responses; they do not prove real lifecycle transitions or change data.