# Send records to a webhook

Use **HTTP webhook fan-out** to load records and send one HTTP POST per record to a destination webhook. The prepared workflow also retains the HTTP job's output for inspection.

## Configure the request

| Parameter | What to enter |
| --- | --- |
| `workflow_name` | A nonempty workflow name. |
| `data_source_id` | The retained-record source to deliver. |
| `limit` | Records to load: 1–5,000, default 200. |
| `webhook_url` | The approved destination URL. |
| `webhook_key_prefix` | Prefix for request identity and retained record type; default `wf-fanout`. |

Choose a destination you control or have permission to call. Review the data that will leave Strive and configure any required authentication through the supported connection/request settings. A URL alone does not guarantee the receiver accepts the request.

## Test delivery

1. Select the template and enter the source and webhook URL.
2. Start with a source containing only a few safe test records.
3. Create the workflow and inspect `load → post → persist`.
4. Review the HTTP handler's body and response behavior against the webhook's contract.
5. Validate, then start a Manual real run.
6. Inspect both the receiver and the retained response records.

The POST job uses concurrency 4 and a 15-second timeout setting. Change these only after measuring the receiver's limits. The source loader is not batched in this recipe, so `limit` bounds the selected input rather than guaranteeing a complete export.

## Understand repetition

Each request carries an idempotency key built from the configured prefix, run identity, and record sequence. The receiver must honor that key to deduplicate a repeated attempt. A separate run creates different keys and can cause the external action again.

This HTTP fan-out does not checkpoint each request as an independent batch. A late failure can leave earlier requests delivered. Inspect the receiver before retrying a failed or cancelled run.

The retained record type uses `webhook_key_prefix`; choose a meaningful value if consumers rely on it. Stored responses describe the operation but do not prove the receiver completed a longer downstream business process.

Dry-run suppression of POST does not test live delivery. See [HTTP request](/docs/steps/http-request), [dry runs](/docs/workflows/dry-runs), and [reliability](/docs/workflows/reliability).

## Prepared job settings

The starter is enabled and uses a Manual trigger. These settings are supplied by the recipe; review them in the editor before adapting the process. `${…}` values below refer to the corresponding template parameter or run variable.

| Setting | Prepared value |
| --- | --- |
| `load.config.data_source_id` | `"${data_source_id}"` |
| `load.config.limit` | `"${limit}"` |
| `post.config.url` | `"${webhook_url}"` |
| `post.config.method` | `"POST"` |
| `post.config.concurrency` | `4` |
| `post.config.timeout_seconds` | `15` |
| `post.config.idempotency_key_template` | `"${webhook_key_prefix}:${run_id}:${record_seq}"` |
| `persist.config.record_type` | `"${webhook_key_prefix}"` |
| `persist.config.idempotency_key_template` | `"${run_id}:${record_seq}"` |