Send records to a webhook
POST a bounded set of records and retain the response records.
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
- Select the template and enter the source and webhook URL.
- Start with a source containing only a few safe test records.
- Create the workflow and inspect
load → post → persist. - Review the HTTP handler's body and response behavior against the webhook's contract.
- Validate, then start a Manual real run.
- 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, dry runs, and 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}" |