Get / Update / Delete / Preview

Get binding details, update signal filters, field maps, or excluded fields, delete a binding, or preview the resolved and serialized payload without sending.

Manage a single delivery binding: retrieve its configuration, update the signal filter or field map, delete it, or preview the payload it would produce. Updates re-validate the compatibility triangle. Deleting a binding stops future routing but allows in-flight deliveries to complete.

Use GET to inspect the current binding config and last_status. Use PUT to adjust the signal filter, field map, or retry policy — changes take effect on the next matching event. Use DELETE when the binding is no longer needed; in-flight deliveries already in the job queue will still complete.

The PUT response returns the full updated binding. The compatibility triangle is re-validated on every update — if you change the signal_filter.event_type or serializer_format, the system verifies the new combination is still valid. The preview endpoint (POST /preview) walks the resolve-project-serialize flow with a synthetic event and returns the wire output without delivering.

Pair updates with the delivery history endpoint to verify the binding is producing expected results. If last_status shows failed, check the DLQ for error details before adjusting the binding config.

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": "succeeded",
  "created_at": "2024-09-10T09:00:00.000Z",
  "updated_at": "2024-09-10T09:00:00.000Z"
}

Errors

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", "date": "$.invoice_date" },
  "delivery_policy": { "max_attempts": 7 },
  "is_active": true,
  "last_status": "succeeded",
  "created_at": "2024-09-10T09:00:00.000Z",
  "updated_at": "2024-09-16T10:00:00.000Z"
}

Errors

Response

{
  "deleted": true
}

Errors

Preview Response

On the public API this route currently returns the placeholder { "preview": "not-implemented-in-slice-1-MVP" }; the full preview described below is what the wired preview service returns today — it backs the platform's binding editor — and is the shape this route serves once the public wiring lands. The preview builds a synthetic event matching the binding's signal_filter, then walks the delivery pipeline up to — but not including — the connector call. When the resolver can produce a real payload, sample_mode is real and the response carries the projected payload, the serialized bytes, and a wire_preview of the body and headers. When the synthetic entity cannot resolve (typically because the referenced entity does not exist yet), the preview degrades to sample_mode: "structural": it returns the resolver's declared shape with a fallback_reason instead of concrete data.

For a binding that carries excluded_fields, the response also includes exclusion_check — the only surface where a misconfigured exclusion is caught. checked: true means a real payload was resolved and unmatched_keys lists the exclusion entries that matched no field on it (matching is exact and case-sensitive, so an unmatched key is usually a typo or a renamed field — and it withholds nothing at delivery time); an empty array means every key matched. checked: false means the preview could not verify the keys — the structural fallback has no payload to check against — and reason says why. It is not a claim that the keys match.

{
  "available": true,
  "sample_mode": "real",
  "signal": { "type": "document.structured", "document_id": "…", "pipeline_id": "…" },
  "resolver": { "type": "pipeline.capture", "shape": { "kind": "record", "is_collection": false, "columns": [] } },
  "projected": { "fields": { "vendor_name": "Acme Corp", "total_amount": "1250.00" } },
  "serialized": { "mime": "application/json", "size_bytes": 182 },
  "wire_preview": {
    "body_preview": "{\"fields\":{\"vendor_name\":\"Acme Corp\",\"total_amount\":\"1250.00\"}}",
    "mime": "application/json",
    "size_bytes": 182,
    "headers_preview": { "X-Talonic-Idempotency-Key": "a3f8c2d1e4b7…" }
  },
  "exclusion_check": {
    "checked": true,
    "unmatched_keys": ["SQL_Data"]
  }
}

Errors