Skip to main content

Event Feed

Poll GET /v1/events for a newest-first feed of platform events. The feed reads the same rows webhooks fan out from, so you can reconcile missed deliveries.

GET /v1/events is the pull-side counterpart to webhooks: a newest-first, read-only feed of everything that happened in the workspace. Document extractions, run completions and failures, review verdicts, delivery outcomes, and case resolutions all appear as events with their type, payload, and timestamp. Webhooks push these events to your server; the feed lets you pull them on your own schedule.

The feed reads the same rows webhooks are fanned out from, so it is the reconciliation tool for missed deliveries: if your endpoint was down and a webhook exhausted its retries, the event is still in the feed. A consumer that stores the id of the last event it processed passes it as after and pages forward from there, which closes any gap without counting offsets.

The feed has two paging modes. Offset mode (no after) returns events newest first, ordered by created_at then id, paged with limit and offset. Cursor mode (after=<event id>) returns events with a higher id in ascending order and ignores offset, so a consumer reads forward in the order events happened. Every non-empty page carries next_cursor: in cursor mode it is the last id on the page, in offset mode the highest id on the page, so you can switch from an initial newest-first look into cursor mode. next_cursor is null only on an empty page. since (ISO 8601) restricts either mode to events created at or after that time, and event_type accepts a comma-separated list.

GET/v1/events

Query parameters

event_typestringFilter by event type. Comma-separated for several, for example document.extracted,field.merged.
afterstringCursor mode: return events with an id greater than this numeric event id, oldest first. A non-numeric value is a 400.
sincestringISO 8601 timestamp; only events created at or after it.
limitintegerMaximum events to return (1 to 200). Default: 50
offsetintegerNumber of events to skip (offset mode only; ignored with after). Default: 0

Response

Response fields

dataarrayEvent objects, newest first.
data[].idstringEvent ID (numeric, as a string). Monotonically increasing, so it doubles as a cursor.
data[].event_typestringEvent type, for example document.extracted or delivery.item.failed.
data[].payloadobjectEvent-specific payload, the same object a webhook for this event carries.
data[].created_atstringISO 8601 timestamp of when the event was recorded.
totalintegerTotal matching events.
limitintegerApplied page size.
offsetintegerApplied offset.
next_cursorstring | nullPass as after to read the next page forward. Null only when the page is empty.

curl

curl -s "https://api.talonic.com/v1/events?event_type=document.extracted&limit=20" \
  -H "Authorization: Bearer $TALONIC_API_KEY"

Response

{
  "data": [
    {
      "id": "98771",
      "event_type": "document.extracted",
      "payload": {
        "document_id": "c3d4e5f6-a7b8-9012-cdef-123456789012",
        "filename": "invoice-0847.pdf"
      },
      "created_at": "2026-07-14T21:06:48.977Z"
    }
  ],
  "total": 1280,
  "limit": 20,
  "offset": 0,
  "next_cursor": "98771"
}

Cursor mode: read forward from the last processed event

curl -s "https://api.talonic.com/v1/events?after=98771&event_type=pipeline.cancelled,field.merged&limit=100" \
  -H "Authorization: Bearer $TALONIC_API_KEY"
# Repeat with after=<next_cursor> until data is empty.
Webhook event names and feed event types are two vocabularies over the same activity: the feed uses internal signal types such as document.extracted and delivery.item.failed, while webhook configurations use the public names listed on the Events page. Filter the feed by the types you observe in your own responses.

A robust integration treats webhooks as the fast path and the feed as the source of truth: process webhooks as they arrive, and run a periodic sweep that pages the feed for anything the webhook path missed. Because event IDs are monotonically increasing, cursor mode with after set to the last processed ID returns exactly the gap to close.

Frequently asked questions

How is the event feed different from webhooks?+
Same events, opposite direction. Webhooks push events to your server as they happen; GET /v1/events lets you pull them newest-first on your own schedule. The feed reads the same underlying rows webhooks fan out from.
Can I use the feed to recover events my webhook endpoint missed?+
Yes, that is its main purpose. Events remain in the feed even when every webhook delivery attempt for them failed, so a periodic sweep of the feed closes any gap left by endpoint downtime.
Is GET /v1/events different from GET /v1/delivery/events?+
Yes. Both read the same outbox rows, but GET /v1/events is the consumer feed: comma-separated event_type, since, cursor paging with after and next_cursor, and a { data, total, limit, offset, next_cursor } envelope. GET /v1/delivery/events is the operator view with processing status per event, a single exact event_type filter, and offset paging only.
How do I page the feed without missing events?+
Use cursor mode. Store the id of the last event you processed and call GET /v1/events?after=<id>; events come back oldest first. Repeat with the returned next_cursor until a page is empty.

Related

Events
Retry Policy
Machine-Readable Reference Endpoints