Debugging your integration

​

Request logs

curl "https://api.listo.delivery/v1/request_logs?status=failed" \
  -H "Authorization: Bearer $LISTO_API_KEY"

{
  "data": [
    {
      "id": "req_4f9c2b7e1a8d3056b1c2d3e4",
      "method": "POST",
      "path": "/v1/deliveries",
      "endpoint": "api/v1/deliveries#create",
      "status": 422,
      "error_code": "validation_failed",
      "duration_ms": 118,
      "request_id": "0b1f6c9a-7e2d-4c53-9a41-5d8e3f2a6b10",
      "api_key_prefix": "lst_test_Ab1",
      "test": true,
      "created_at": "2026-11-06T16:02:11Z"
    }
  ],
  "has_more": false,
  "cursor": null
}

• Calls that identified a key. A call with no key, or a wrong or revoked one, belongs to nobody and is not in your log, and neither is a call refused for rate limiting. If you are certain you made a call and it is missing, one of those is the reason.
• Keys and one-time links are masked. An API key anywhere in a body reads as its first characters followed by [key masked], and the link in the response to POST /v1/connect_requests or to a Stripe onboarding call reads [redacted: one-time link], because holding that link is the authority to use it. What you received is untouched; only the stored copy is masked. Headers are never kept.
• A body is cut at 64 KB. A longer one is kept as an object with _listo_truncated: true, the original_bytes it had and the first 64 KB of its text, so you are always told that you are not reading all of it.
• The three debugging reads keep no bodies. Reading the request log, the events or the webhook deliveries is itself logged, but without bodies: otherwise the log would copy itself every time you read it. Their request_body and response_body are null.
• Rows are kept. There is no retention window to race. A row from before this log was available has no path or request_id, both null.

​

Events

​

Webhook deliveries

{
  "id": "whd_8d2e5f1a7c3b9046a1b2c3d4",
  "event_id": "evt_9pQ2vX7mKdR4tYb1nZ3sLwCe",
  "event_type": "delivery.status_changed",
  "attempt": 2,
  "resent": false,
  "url": "https://example.com/listo/webhooks",
  "status_code": null,
  "error_message": "execution expired",
  "response_body": null,
  "duration_ms": 5000,
  "succeeded": false,
  "created_at": "2026-11-06T16:04:31Z"
}

​

Send an event again

curl -X POST "https://api.listo.delivery/v1/events/evt_9pQ2vX7mKdR4tYb1nZ3sLwCe/resend" \
  -H "Authorization: Bearer $LISTO_API_KEY"

• The same event. It has the same id and the byte-identical body, so a receiver that deduplicates on id, as it should, treats it as the event it already saw. To exercise your handler again, clear that record first.
• Signed now. The signature carries the current time and the current secret, so it verifies even when the event is days old.
• Sent to the current URL. If you changed your endpoint since the event happened, the resend goes to the new one.
• Once. There is no retry behind it. If your endpoint fails, you see one failed attempt and you decide what to do next.
• Limited. An event can be resent 5 times an hour. The sixth is refused with 429 resend_limit_reached, which is retryable once the hour has passed. Retry-After says how many seconds until you can send again.
• Never a courier position. A delivery.courier_location event is superseded by the next one within seconds, so asking to resend one is 409 event_not_resendable.
• Needs an endpoint. With no webhook URL configured for the key’s mode the answer is 409 webhook_endpoint_not_configured.

​

Send a test webhook

curl -X POST "https://api.listo.delivery/v1/test_webhooks" \
  -H "Authorization: Bearer $LISTO_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"type": "delivery.status_changed"}'

{
  "id": "evt_3kM7qR2vX9pNdY4tB6nZ1sLw",
  "type": "delivery.status_changed",
  "created_at": "2026-11-06T16:10:02Z",
  "test": true,
  "data": {
    "id": "dlv_test_sample_000000000000",
    "external_id": "order-841",
    "status": "en_route"
  }
}

• "test": true is on the envelope. A real event does not carry the field at all. Branch on it before you do anything with consequences.
• Its ids resolve to nothing. data is a realistic sample of the type, but the delivery, store, withdrawal or quote it names does not exist, so GET /v1/deliveries/{id} for it answers 404. A handler that reads the object back, as it should, will find nothing, which is the proof that it is a test.
• It works in both modes. A test key sends to your test endpoint and a live key sends to your live one, so you can check a production endpoint without placing an order. That live endpoint does receive the test event, so make sure it is ignored there.
• It is limited. 30 test events an hour per mode, then 429 test_webhook_limit_reached, and Retry-After says how many seconds until you can send again. A type that is not a published name is 422 validation_failed with param: "type", and a mode with no webhook URL is 409 webhook_endpoint_not_configured.

​

What these endpoints refuse with

​

In the dashboard

• Request logs lists your calls with the same filters, and each call opens to its request and response bodies.
• Webhooks keeps the endpoint settings and shows each attempt. Resend sits on every attempt of an event that can be resent, and Send test webhook sends a synthetic event to the endpoint above it.

​

Debug with your AI assistant

​

A way to work

1. Reproduce the problem with a test key, so nothing real is at stake.
2. Open the call in the request log. The status, error.code and message of the response body, and your own request body, answer most questions.
3. If it was an event you were waiting for, find it in GET /v1/events, then its attempts in GET /v1/webhook_deliveries.
4. Fix the handler, then resend that event, or send a test webhook, until the attempt reads succeeded.
5. Check the same on the live endpoint with a test webhook before you rely on it.