Skip to content
First DeliveryFirst DeliveryFirst Delivery API

Debugging

Start with the smallest reproducible request in sandbox.

Record:

  • environment, UTC timestamp, method, and path;
  • HTTP status and redacted response body;
  • First Delivery order ID and your external ID;
  • request ID or job ID when returned;
  • webhook event ID and destination hostname for webhook failures.

Request provenance in Dispatch can show the integration route and request identifiers associated with an order. The webhook event log shows recent delivery attempts and responses.

Request provenance in an order history

The provenance view distinguishes named API clients, legacy operator keys, partner webhooks, browser sessions, and development tools such as Postman. Use it to confirm which credential and route produced an order before rotating a key or changing an integration.

Never share API keys, authorization headers, full webhook secrets, or unredacted customer names, phone numbers, and addresses. Avoid inferring which API client made old traffic when the recorded request does not contain a client ID.

For transient failures, use exponential backoff with jitter and a retry limit. Do not retry validation errors unchanged. Before retrying a create request after a timeout, reconcile by external identifier to avoid duplicates.

Recent order history is kept in the live database for the documented retention window. Older orders may be hydrated from archive and marked with hydrated_from: "archive". A temporary archive read failure returns 503; retry it rather than treating the order as missing.