Bindings

A binding is the routing rule: it joins a signal filter (which events?) to a deliverable type (what payload shape?) to a destination (ship where?) via a serializer (encoded how?). On create, the backend validates all four pieces form a compatible triangle — the serializer must support the resolver's shape, and the connector must support the serializer format. This six-predicate validation ensures you never end up with a misconfigured binding that cannot deliver.

Optional field_map (rename/drop/static rules) lets you reshape the payload without custom code. The three operations compose in order: drop excluded fields first, then rename remaining fields, then inject static values. Optional delivery_policy overrides the default retry ladder (7 attempts over ~10 hours with exponential backoff: 0s, 30s, 2min, 8min, 30min, 2h, 8h) and maximum attempts.

The compatibility triangle is enforced on every create and update via six predicates. The backend checks that: (1) the signal_filter is well-formed with a known event type and valid match values, (2) the deliverable_type resolves to a registered resolver, (3) the serializer_format resolves to a registered serializer, (4) the serializer supports the resolver's output shape, (5) the connector's supported serializer list includes the chosen format, and (6) the resolver's compatible signals include the signal filter's event type. If any predicate fails, the binding is rejected with a descriptive error — you never end up with a binding that cannot deliver.

Use field_map to tailor the payload for each downstream consumer. Rename rules map internal field names to the receiver's expected names. Drop rules exclude fields the receiver does not need. Static rules inject constant values (e.g., a source: "talonic" tag) into every payload. These three operations compose in order: drop first, then rename, then static injection.

For best results, create one binding per downstream consumer per event type. This gives you independent control over payload shape, retry policy, and serialization format for each integration point. Most teams start with a document.extracted binding to a webhook and expand to run-level and approval signals as their pipeline matures.

curl -X POST https://api.talonic.com/v1/delivery/bindings \
  -H "Authorization: Bearer $TALONIC_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Approved records to S3 as CSV",
    "signal_filter": { "event_type": "result.approved" },
    "deliverable_type": "record.approved",
    "destination_id": "dest_s3",
    "serializer_format": "csv_file",
    "field_map": {
      "rename": { "invoice_number": "inv_no", "total_amount": "amount" },
      "drop": ["internal_notes", "debug_trace"],
      "static": { "source": "talonic", "pipeline": "production" }
    },
    "delivery_policy": {
      "max_attempts": 5,
      "backoff_schedule": [0, 10000, 60000, 300000, 1800000]
    }
  }'

The field_map feature eliminates the need for middleware transformation layers between Talonic and your downstream systems. The three operations — drop, rename, and static injection — compose in a fixed order: excluded fields are removed first, then remaining fields are renamed to match your downstream schema, then static values are injected. This means you can reshape the payload to match exactly what your ERP, data warehouse, or analytics system expects without writing any code or deploying a transformation service. Most teams create one binding per downstream consumer per event type for independent control over payload shape.