Pending & Events

Inspect and cancel pending delivery retries before they fire, list the raw outbox events that drive delivery bindings, and replay any event on demand via API.

Two surfaces sit underneath the delivery items and dead-letter queue: the pending retries — delivery jobs sitting in the queue that have not run yet — and the raw delivery events, the outbox rows that bindings consume. Use them to see what is scheduled to go out, cancel a queued retry before it fires, and replay an event through the whole binding flow from the source signal.

A pending retry is a queued delivery job in one of three states: delayed (scheduled for a future backoff slot), waiting (runnable, awaiting a worker), or active (currently executing). The pending list groups counts by state and lists each job with its binding, event, attempt number, and — for delayed jobs — the wall-clock time of the next attempt. Cancel a single job by its job_id, cancel every pending retry for one binding, or clear the whole tenant queue in one call.

Events are the upstream signals — domain occurrences like a document structured or a run completed — recorded in the delivery outbox before any binding matching happens. Each row shows whether it was dispatched (processing_status: "enqueued"), matched nothing (no-subscribers), or failed to process. Replaying an event marks it unprocessed so the poller re-dispatches it on its next tick, fanning out to every binding that matches now — including bindings created after the event originally fired.

The two replay verbs compose into a debugging workflow: when a delivery went wrong, check the item history first (was the payload built and rejected?), then the DLQ (did it exhaust retries?), and reach for event replay when the problem was routing — a binding that did not exist yet, was inactive, or had the wrong signal filter when the event first fired.

Pending Response

curl -s https://api.talonic.com/v1/delivery/pending \
  -H "Authorization: Bearer tlnc_your_api_key"

{
  "counts": { "delayed": 2, "waiting": 0, "active": 1 },
  "items": [
    {
      "job_id": "18234",
      "event_id": "98765",
      "binding_id": "d4e5f6a7-b8c9-0123-defa-345678901234",
      "attempt": 3,
      "status": "delayed",
      "next_attempt_at": "2026-08-29T12:08:00.000Z"
    }
  ]
}

Listing and replaying events

The events list is the outbox log, newest first, with an optional event_type filter and limit/offset paging (default 50 per page). Each row carries the full signal payload that resolvers receive, plus processing bookkeeping: processed_at, processing_attempts, processing_status, and error. A no-subscribers status means the event fired but no active binding matched it — the usual first clue when an expected delivery never appears in the item history.

{
  "items": [
    {
      "id": "98765",
      "event_type": "document.structured",
      "payload": { "document_id": "doc-a1b2…", "pipeline_id": "p-c3d4…" },
      "dedup_key": "doc:doc-a1b2…:structured:p-c3d4…",
      "created_at": "2026-08-29T11:59:59.000Z",
      "processed_at": "2026-08-29T12:00:00.000Z",
      "processing_attempts": 1,
      "processing_status": "enqueued",
      "error": null
    }
  ],
  "total": 412
}