Signals & Catalog

The catalog API (/v1/delivery/catalog/*) exposes the four registries that drive the binding picker: signals, deliverables, serializers, and connectors. Use it to populate dropdowns rather than hardcoding lists — it always reflects the running registry contents. When new signal types or deliverable resolvers are added to the platform, they appear automatically in the catalog without any configuration changes on your end.

Signals are typed events emitted by the platform when meaningful state changes occur. They fall into four categories. Document signals (document.extracted, document.extraction_failed) fire on extraction success or failure for individual documents. Run signals (run.dataspace.completed, run.structuring.completed, run.resolution.completed, run.extraction.completed) fire when a job run completes across the four pipeline domains. Result signals (result.approved, result.rejected, result.flagged) fire when a reviewer takes action on a record. Meta-signals (delivery.item.completed, delivery.item.failed) fire when a delivery attempt itself succeeds or fails, enabling self-monitoring workflows.

The two delivery.item.* entries are meta-signals — 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-signal delivery does not emit another meta-signal.

For best results, use the catalog API to populate dropdown menus and configuration forms rather than hardcoding signal or deliverable lists. The catalog always reflects the running registry contents, so new signal 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 signal 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 signal 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.