# Write via connector

Deliver the records to a registered connector or a stored Connection.

## When to use it

Deliver records to a chosen connection. Outputs indicate whether each input was written. A retry can deliver data again: duplicate prevention depends on a configured key and a destination that honours it. Batch processing can checkpoint completed slices.

## Add and configure

1. Add **Write via connector** from the workflow step picker.
2. Give the step a recognisable name and connect its required inputs.
3. Set the options below. Nested names identify fields within an object or a list item.
4. Validate the recipe, inspect the test result, then run it on the intended data.

The step identifier used in the editor’s code view is `connector_write`.

## Settings

| Setting | Accepted value | Required | Default | What it controls |
| --- | --- | --- | --- | --- |
| Catalog Slug (`catalog_slug`) | string or null | No | null | Connection-backed form: the connection's catalog slug. |
| Config (`config`) | object | No | Not specified | Per-step connector options. With a saved connection, these override its ordinary options; access identity remains controlled by the connection. |
| Connection Id (`connection_id`) | string; format uuid or null | No | null | Connection-backed form: the stored Connection to write to. When set, the connector name + config/secrets are resolved from the connection's catalog_slug at run time. |
| Connector (`connector`) | string or null | No | null | Registered connector name (inline form). |
| Display Name (`display_name`) | string; maximum characters 200 or null | No | null | Destination label shown in Data. Choose a recognisable name for the delivered records. |
| Idempotency Key Template (`idempotency_key_template`) | string or null | No | null | Renders one key per chunk from variables `${tenant_id}`, `${run_id}`, `${step_id}`, `${chunk_seq}`. Connectors that recognize idempotency keys use them for dedup; others log them. |
| Secrets (`secrets`) | object or null | No | null | Optional connector secrets payload (inline form). |

## Inputs and outputs

| Direction | Port | Content | Required | Multiple records |
| --- | --- | --- | --- | --- |
| Inputs | `in` | records | Yes | Yes |
| Outputs | `out` | records | Yes | Yes |

## Effects, testing, and recovery

Can write or act on an external destination.

The declared preview behaviour is to skip this step. Configuration can affect preview behaviour; HTTP GET is a notable exception. Read [dry runs](/docs/workflows/dry-runs) before using a preview with live connections.

Duplicate prevention uses the configured or operation-bound key; an external receiver must recognise it. Do not assume that manually repeating the step is free of repeated effects.

Batch processing is supported; the declared default slice is 500 records. Inspect completed slices before repeating a partial delivery.

## Example: Connection-backed write into the platform database

Step settings:

```json
{
  "catalog_slug": "platform_database",
  "connection_id": "22222222-2222-4222-8222-222222222222",
  "idempotency_key_template": "${run_id}:${step_id}:${chunk_seq}"
}
```

## Example: Inline HTTP connector posting to an endpoint

Step settings:

```json
{
  "config": {
    "url": "https://ingest.example.com/records"
  },
  "connector": "http",
  "display_name": "Ingest API"
}
```

## Check the result

Inspect the selected run’s status, counts, errors, and output records. An empty collection can be a valid result, and a completed step can contain per-record failures where the step defines that behaviour. Check the next step’s expected record shape before publishing or delivering the result.