Outbound Webhook Workflow Action in Sparkforge

The outbound Webhook action sends data from a Sparkforge workflow to an external URL in real time. When a contact reaches the webhook step, Sparkforge packages the relevant data into a payload and POSTs (or GETs) it to the URL you provide. Anything that accepts an HTTP request can receive it.

What it's good for

• Custom integrations: connect to any third-party app or internal system.
• Real-time sync: push contact and event data to external databases, spreadsheets, or analytics tools as it happens.
• Bespoke automation: trigger processes that aren't covered by native integrations — direct mail, custom CRMs, course platforms.
• Reporting pipelines: feed BI tools with workflow events.

Configuration fields

How to configure

1. Drop the Webhook action into your workflow.
2. Pick the HTTP method the destination expects.
3. Paste the destination URL.
4. Add headers — common ones: Content-Type: application/json and an auth header like Authorization: Bearer YOUR_TOKEN.
5. Add query parameters if the endpoint requires them.
6. Build the request body. Use custom values to inject contact data, e.g. {"email": "{{contact.email}}", "name": "{{contact.name}}"}.
7. Test by running a sample contact through the workflow. Check your destination logs to confirm receipt.
8. Save the workflow.

Common payload structure

{
  "contact_id": "{{contact.id}}",
  "email": "{{contact.email}}",
  "phone": "{{contact.phone}}",
  "first_name": "{{contact.first_name}}",
  "last_name": "{{contact.last_name}}",
  "event": "workflow_triggered",
  "timestamp": "{{system.now}}"
}

Authentication patterns

• Bearer token: Authorization: Bearer YOUR_TOKEN in the headers.
• API key: custom header like X-API-Key: YOUR_KEY, or as a query parameter.
• Basic auth: Authorization: Basic BASE64_ENCODED.
• HMAC signature: rare in workflow webhooks — most destinations accept tokens.

Testing and debugging

1. Use a sandbox URL like webhook.site or RequestBin to inspect the actual payload Sparkforge sends.
2. Run one contact through the workflow.
3. Check the inspector for headers, body, and query parameters.
4. Once verified, swap the URL to your production endpoint.

Failure handling

If the destination returns a non-2xx status, Sparkforge logs the failure on the workflow execution. Check workflow execution logs to find failed webhook calls. For destinations that go down occasionally, consider building retry logic on the receiving side or pointing the webhook at a queue (e.g. an SQS endpoint) that absorbs failures.

When to use a webhook vs. native integration

• Native integration exists and covers your use case → use the native action.
• No native integration, or you need to send custom data → outbound webhook.
• You need bidirectional sync (data in and out) → pair an outbound webhook with an inbound webhook trigger.