Signals & Catalog

Delivery events are the typed events Talonic emits when meaningful state changes occur (the delivery API refers to them as *signals*, as in the signal_filter field and the /catalog/signals registry), and the catalog API (/v1/delivery/catalog/*) exposes the four registries that drive the binding picker: signals, deliverables, serializers, and connectors. Use the catalog to populate dropdowns rather than hardcoding lists — it always reflects the running registry contents. When new event types or deliverable resolvers are added to the platform, they appear automatically in the catalog without any configuration changes on your end.

Events fall into four categories. Document events (document.extracted, document.extraction_failed) fire on extraction success or failure for individual documents. Run events (run.dataspace.completed, run.structuring.completed, run.resolution.completed, run.extraction.completed) fire when a run completes across the four run domains; each also has a .failed counterpart (e.g. run.structuring.failed) for terminal run failures. Result events (result.approved, result.rejected, result.flagged) fire when a reviewer takes action on a record. Meta-events (delivery.item.completed, delivery.item.failed) fire when a delivery attempt itself succeeds or fails, enabling self-monitoring workflows. The table above lists the core types; GET /v1/delivery/catalog/signals is the exhaustive, always-current list.

The two delivery.item.* entries are meta-events — they fire when a delivery itself succeeds or fails. Use them for self-monitoring: bind delivery.item.failed to a notification webhook to receive alerts when deliveries break. The poller includes built-in loop prevention so a failed meta-event delivery does not emit another meta-event.

For best results, use the catalog API to populate dropdown menus and configuration forms rather than hardcoding event or deliverable lists. The catalog always reflects the running registry contents, so new event types and deliverables appear automatically as the platform evolves.

# List all available signal types:
curl -s https://api.talonic.com/v1/delivery/catalog/signals \
  -H "Authorization: Bearer $TALONIC_API_KEY"

# Response:
# {
#   "types": ["document.extracted", "document.extraction_failed",
#     "run.dataspace.completed", "run.structuring.completed",
#     "run.resolution.completed", "run.extraction.completed",
#     "result.approved", "result.rejected", "result.flagged",
#     "delivery.item.completed", "delivery.item.failed"],
#   "items": [
#     {
#       "type": "document.extracted",
#       "label": "Document extracted",
#       "description": "Fired when a document completes extraction"
#     }
#   ]
# }

# List compatible deliverables, serializers, and connectors:
# GET /v1/delivery/catalog/deliverables
# GET /v1/delivery/catalog/serializers
# GET /v1/delivery/catalog/connectors

The catalog API is designed for dynamic UI integration. Rather than hardcoding event types or deliverable options in your application, query the catalog endpoints to populate dropdowns and configuration forms. This ensures your integration stays current as the platform evolves — new event types, deliverable resolvers, and serializers appear automatically in the catalog when they are registered. The catalog also powers the compatibility triangle in the binding editor, filtering options at each step to show only compatible choices.