Create Binding

Create a delivery binding that routes domain events through a deliverable resolver and serializer to a destination, with field mapping and retry policy.

Create a binding that wires a domain event to a destination. The compatibility triangle is validated on creation: the signal event type must be compatible with the deliverable resolver, the serializer must support the deliverable shape, and the connector must support the serializer format.

The typical workflow is: query the catalog endpoints top-down (signals, then deliverables, then serializers, then connectors), pick compatible values, and create the binding. A single event can fan out to multiple bindings — create separate bindings for each destination or output format you need.

The response returns the binding with is_active: true and last_status: null. The field_map controls payload projection: use static to inject fixed values, drop to remove fields, and key-value pairs to rename fields. The delivery_policy defaults to 7 attempts with exponential backoff over ~10 hours if omitted.

After creation, the binding is immediately live — the next matching event will trigger delivery. Use the binding preview to dry-run the resolve-project-serialize flow. Monitor delivery health via the history and DLQ endpoints.

Withholding fields with excluded_fields

The optional excluded_fields array is a binding-level egress filter: every field key it names is omitted from the delivered payload for this destination. It accepts up to 200 entries of 1-256 characters each, and it is the intended tool for pipeline-internal fields — join payloads like a matched reference row — that downstream stages consume but this particular destination must not receive. This is the only per-destination field withhold: a schema field's suppress_output or a resolution-policy include: false hides the field from the data product itself, not from the delivered capture payload.

Exclusions are honored by the pipeline.capture deliverable only, and the API rejects a create or update that sets excluded_fields on any other deliverable_type — on other deliverables the list would persist but every delivery would still ship the field, a silent no-op on a data-egress control. Matching against the payload is exact and case-sensitive on the schema field_name / cell field_key; an excluded field is removed both from the declared-field seed and from the cell overlay, so a populated cell cannot leak through.

{
  "name": "Notify on extraction complete",
  "signal_filter": { "event_type": "document.extraction.completed" },
  "deliverable_type": "document_capture",
  "serializer_format": "json",
  "destination_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "field_map": { "vendor": "$.vendor_name", "total": "$.amount" },
  "delivery_policy": { "max_attempts": 5, "backoff_schedule": [1000, 5000, 30000] }
}

Response

{
  "id": "d4e5f6a7-b8c9-0123-defa-345678901234",
  "name": "Notify on extraction complete",
  "signal_filter": { "event_type": "document.extraction.completed" },
  "deliverable_type": "document_capture",
  "destination_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "serializer_format": "json",
  "serializer_config": {},
  "field_map": { "vendor": "$.vendor_name", "total": "$.amount" },
  "delivery_policy": { "max_attempts": 5, "backoff_schedule": [1000, 5000, 30000] },
  "is_active": true,
  "last_status": null,
  "created_at": "2024-09-10T09:00:00.000Z",
  "updated_at": "2024-09-10T09:00:00.000Z"
}

Errors