Skip to main content

Delivery Config

Get and replace a Spec's delivery configuration: the outbound settings the pipeline uses when routing produced data to destinations after a run finishes.

The delivery config is the Spec outbound configuration. It captures how a finished run routes its produced data to destinations — the settings the Spec editor's Delivery stage edits. The GET endpoint reads the current config, and the POST endpoint replaces it wholesale. An unset config reads back as an empty object, which is the state of every freshly created Spec.

The config body is a free-form JSON object, so the exact keys depend on how your delivery is wired (bindings, formats, and destinations). The Spec stores the object under delivery_config and echoes the stored object back as the POST response. POST replaces the stored object rather than merging, so the safe editing pattern is read-modify-write: GET the current config, change the keys you want, and send the whole object back.

Note what this config is not: it does not create destinations or bindings by itself. Destinations (where data lands) and bindings (which signals fire deliveries) are managed by the delivery endpoints under /v1/delivery, and webhook subscriptions by /v1/webhooks. The Spec's delivery config carries the Spec-level shaping on top of that wiring — for example the export format and the mapping from Spec field names to the column headers a destination expects.

Reads require the read scope and writes the write scope, like the rest of the Spec-config surface. Both routes 404 for a schema id that does not exist under your organization — a foreign tenant's Spec is indistinguishable from a missing one.

GET/v1/schemas/{id}/delivery
POST/v1/schemas/{id}/delivery

Body parameters

<key>anyFree-form delivery configuration. The object is stored under delivery_config and replaces any existing config.

Read the config

curl -s https://api.talonic.com/v1/schemas/a1b2c3d4-e5f6-7890-abcd-ef1234567890/delivery \
  -H "Authorization: Bearer tlnc_your_api_key"

Replace the config

curl -X POST https://api.talonic.com/v1/schemas/a1b2c3d4-e5f6-7890-abcd-ef1234567890/delivery \
  -H "Authorization: Bearer tlnc_your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "format": "csv",
    "destination_id": "9f8e7d6c-5b4a-3210-fedc-ba9876543210",
    "field_map": {
      "invoice_number": "Invoice #",
      "total": "Amount"
    }
  }'

Response

GET returns the stored delivery_config object, or {} when none is set. POST returns the config object as stored — not the whole Spec record — so a successful write echoes back what you sent.

Response (GET delivery)

{
  "format": "csv",
  "destination_id": "9f8e7d6c-5b4a-3210-fedc-ba9876543210",
  "field_map": {
    "invoice_number": "Invoice #",
    "total": "Amount"
  }
}
POST replaces the entire delivery_config object. To change one key, read the current config with GET, modify it, and send the whole object back — a partial POST drops every key it omits.

Errors

Error responses

401unauthorizedMissing or invalid API key.
404not_foundNo Spec (schema) with this ID exists for your organization.
429rate_limitedToo many requests. Retry after the period indicated in the Retry-After header.

Frequently asked questions

Does POST merge or replace the delivery config?+
It replaces the whole object. Read the current config with GET, change the keys you want, and POST the full object back to avoid dropping existing settings.
What keys does the delivery config accept?+
The body is free-form JSON. The keys depend on how your delivery is wired (format, destination, field map, and so on) and mirror what the Spec editor's Delivery stage writes. The Spec stores the object under delivery_config.
What does GET return when no config is set?+
An empty object, `{}`. That is the default state until you POST a config.
Is this where I create webhooks or destinations?+
No. Destinations and delivery bindings are managed under /v1/delivery, and webhook subscriptions under /v1/webhooks. The Spec delivery config only carries the Spec-level shaping (format, field mapping) layered on that wiring.
What does a successful POST return?+
The stored config object itself — the same shape a subsequent GET returns — not the whole Spec record. Verifying a write is therefore a matter of comparing the echo (or a follow-up GET) against what you sent; a missing key in the echo means it was not stored.

Related

Assembly Configs
Samples
Delivery Destinations
Delivery Bindings