Generic Webhook Trigger

The Generic Webhook is a universal HTTP endpoint that accepts POST requests from any source. Unlike service-specific webhooks, it has no provider-specific validation — making it flexible for custom integrations.

Overview

When to Use

• Integrate with services not covered by built-in webhooks
• Receive data from custom applications or scripts
• Build API endpoints that trigger workflows
• Connect IoT devices, monitoring tools, or internal services

Configuration

How It Works

1. Activate the workflow — a unique webhook URL is generated
2. Copy the URL and register it in your external service or script
3. Send HTTP POST requests to that URL with a JSON body
4. The webhook block receives the request and makes the data available to downstream blocks
5. Access the full request body via {{Webhook 1.webhook.data.payload}}
6. Access specific fields via {{Webhook 1.webhook.data.payload.fieldName}}

Internal Data Structure

When a generic webhook receives an HTTP request, the data is stored in a structured format inside the webhook block's output. Understanding this structure is key to correctly referencing data in downstream blocks.

{
  "input": "",
  "webhook": {
    "data": {
      "path": "your-webhook-path-id",
      "provider": "generic",
      "providerConfig": {},
      "payload": {
        // ← This is the raw HTTP body you sent
      },
      "headers": {
        "content-type": "application/json",
        "user-agent": "...",
        // ← All HTTP request headers
      },
      "method": "POST"
    }
  },
  "workflowId": "workflow-uuid"
}

Key Paths

Accessing Data in Downstream Blocks

Use the {{BlockName.path.to.field}} syntax to reference webhook data in any connected downstream block. The block name is the label shown on the canvas (default: Webhook 1).

Name normalization: Block names are case-insensitive and spaces are removed. So {{Webhook 1.field}}, {{webhook1.field}}, and {{WEBHOOK1.field}} all resolve to the same block.

Reference Syntax

{{Webhook 1.webhook.data.payload}}                      → Full request body (JSON object)
{{Webhook 1.webhook.data.payload.fieldName}}             → Top-level field from body
{{Webhook 1.webhook.data.payload.nested.deep.field}}     → Deeply nested field from body
{{Webhook 1.webhook.data.headers}}                       → All HTTP headers
{{Webhook 1.webhook.data.method}}                        → HTTP method string

Example: Simple JSON Body

If an external service sends this POST request:

{
  "event": "order.placed",
  "id": "ord_98765",
  "amount": 49.99,
  "customer": {
    "name": "Jane Doe",
    "email": "jane@example.com"
  }
}

You reference the data as:

Example: Nested Payload with data Wrapper

Many services wrap their event data inside a data object. For example, a messaging platform might send:

{
  "event": "message.received",
  "data": {
    "provider_message_id": "msg_abc123",
    "sender": "+1234567890",
    "content": "Hello world",
    "metadata": {
      "channel": "sms",
      "timestamp": "2025-01-15T10:30:00Z"
    }
  }
}

You reference the data as:

Example: Array Access

If the payload includes arrays, use bracket notation to access specific elements:

{
  "items": [
    { "name": "Widget A", "price": 10 },
    { "name": "Widget B", "price": 20 }
  ]
}

Accessing Headers

HTTP request headers are available as a flat object:

Using Webhook Data in Different Block Types

In an Agent / AI Block

Pass the full payload or specific fields as context:

Process this webhook event: {{Webhook 1.webhook.data.payload}}
The message content is: {{Webhook 1.webhook.data.payload.data.content}}

In a Function Block

Access webhook data inside JavaScript code:

const payload = {{Webhook 1.webhook.data.payload}};
const messageId = payload.data.provider_message_id;
const sender = payload.data.sender;

return { messageId, sender, processed: true };

In a Condition Block

Use webhook fields in conditions to route the workflow:

• Value: {{Webhook 1.webhook.data.payload.event}}
• Operator: equals
• Compare to: order.placed

In an API Block

Forward webhook data to another API:

{
  "event": "{{Webhook 1.webhook.data.payload.event}}",
  "message_id": "{{Webhook 1.webhook.data.payload.data.provider_message_id}}",
  "forwarded_at": "{{Webhook 1.webhook.data.payload.data.metadata.timestamp}}"
}

Example: IoT Data Pipeline

Workflow:

[Webhook 1 (generic webhook)] → [Function: Parse Sensor Data] → [Supabase: Store] → [Condition: Alert?] → [Slack]

IoT sensors send readings via HTTP. Function parses the payload, Supabase stores the data, and if readings exceed thresholds, Slack gets an alert.

Sensor POST:

{
  "device_id": "sensor-42",
  "temperature": 85.5,
  "humidity": 62,
  "timestamp": "2024-03-15T14:30:00Z"
}

Accessing in downstream blocks:

• {{Webhook 1.webhook.data.payload.device_id}} → "sensor-42"
• {{Webhook 1.webhook.data.payload.temperature}} → 85.5
• {{Webhook 1.webhook.data.payload.humidity}} → 62

Quick Reference

Tips

• No signature validation by default — add API key authentication for security
• Works with anything that can send HTTP — scripts, apps, no-code tools, IoT devices
• Parse the body in a Function block if the structure varies between senders
• Block name matters — if you rename the webhook block (e.g., to "Order Hook"), update references to {{Order Hook.webhook.data.payload.field}}
• Use a Function block to reshape — if the nested path is long, use a Function block to extract and flatten the data for simpler references downstream
• Test with curl: curl -X POST https://your-webhook-url -H "Content-Type: application/json" -d '{"test": true}'