Skip to main content
Webhooks are HTTP callbacks — a way for one system to notify another the moment something happens, without polling. In RCB Automation, webhooks work in both directions: you can use an inbound webhook URL as a trigger that starts a workflow when an external service sends data, or you can use an outbound HTTP request as an action that pushes data to any endpoint when your workflow runs.

Inbound webhooks (trigger)

An inbound webhook lets any external service — a payment processor, a form builder, a custom application — start a workflow by sending an HTTP POST request to a unique URL that RCB Automation generates for you.

Set up an inbound webhook trigger

1

Add a webhook trigger to your workflow

Open or create a workflow in the visual builder. Click Add trigger, then select Webhook from the trigger list.
2

Copy your webhook URL

RCB Automation generates a unique URL for this workflow trigger. Copy it — you’ll paste it into the external service in the next step. The URL looks like:
https://hooks.rcbautomation.com/trigger/wh_a1b2c3d4e5f6
3

Configure the sending service

In the external service, find its webhook or notification settings and paste your RCB Automation URL as the destination. Set the request method to POST and the content type to application/json if the service allows you to choose.
4

Send a test event

Trigger a test event from the external service (most have a Send test or Ping button). Return to RCB Automation and click View last payload to confirm the data arrived.
5

Map payload fields to workflow variables

Once RCB Automation has received at least one payload, it displays the payload structure. Click any field to map it as a variable you can reference in later workflow steps.

Example inbound payload

When the sending service POSTs to your webhook URL, the body might look like this:
{
  "event": "order.created",
  "timestamp": "2026-04-20T14:32:00Z",
  "data": {
    "order_id": "ord_9912",
    "customer_email": "alex@example.com",
    "total": 149.99,
    "currency": "USD",
    "items": [
      { "sku": "WIDGET-L", "quantity": 2 }
    ]
  }
}

Outbound webhooks (action)

An outbound webhook sends an HTTP request from your workflow to an external endpoint. Use this to push data to services that don’t have a native RCB Automation integration, or to call internal APIs.

Set up an outbound webhook action

1

Add an HTTP request action

In the workflow builder, click Add action and select HTTP request (or Outbound webhook).
2

Configure the request

Fill in the request details:
  • MethodGET, POST, PUT, PATCH, or DELETE
  • URL — The endpoint you want to call
  • Headers — Add any required headers, such as Content-Type: application/json or an Authorization header
  • Body — For POST, PUT, and PATCH requests, enter the JSON body
3

Insert dynamic data from previous steps

Click inside any field and select Insert variable to reference data from earlier steps. For example, you can build a JSON body that includes the customer email captured by a form trigger:
{
  "to": "{{trigger.fields.email}}",
  "subject": "Thanks for reaching out",
  "order_id": "{{steps.lookup_order.order_id}}"
}
4

Save and test

Click Test step to send the request with sample data and inspect the response. RCB Automation displays the response status code, headers, and body so you can confirm the call succeeded before activating the workflow.

Example outbound requests

curl -X POST https://api.example.com/notifications \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer YOUR_API_TOKEN" \
  -d '{
    "recipient": "alex@example.com",
    "message": "Your order has shipped."
  }'

Securing webhooks

Anyone who knows your inbound webhook URL can send data to it. To prevent spoofed or unauthorized requests from triggering your workflows, use signature verification or a shared secret.

Signature verification

Many services sign their webhook payloads using HMAC-SHA256. The sending service attaches a signature in a request header (commonly X-Signature or X-Hub-Signature-256), computed from the raw request body and a shared secret. To verify the signature in RCB Automation:
  1. In your inbound webhook trigger settings, click Security.
  2. Enable Signature verification and enter the shared secret provided by the sending service.
  3. Select the header name the service uses to send the signature.
RCB Automation will reject any incoming request whose signature doesn’t match, and that event will not trigger the workflow.

Shared secret (basic protection)

If the sending service doesn’t support signatures, you can add a secret token as a query parameter to your webhook URL and check for it in a Condition step at the start of your workflow:
https://hooks.rcbautomation.com/trigger/wh_a1b2c3d4e5f6?token=my-secret-token
Query parameter secrets are less secure than signature verification because the token is visible in server logs. Use signature verification whenever the sending service supports it.

Testing webhooks

You can test inbound webhooks manually using Postman or curl before configuring the sending service.
curl -X POST https://hooks.rcbautomation.com/trigger/wh_a1b2c3d4e5f6 \
  -H "Content-Type: application/json" \
  -d '{"event": "test", "message": "Hello from curl"}'
After sending the request, go to your workflow trigger and click View last payload to confirm RCB Automation received the data correctly.
Use a tool like Webhook.site during development to capture and inspect raw payloads from the sending service before pointing it at your RCB Automation URL. This helps you understand the exact payload structure before mapping fields in the workflow builder.

Webhook delivery logs

RCB Automation keeps a log of every inbound and outbound webhook event associated with your workflows. Viewing logs
  1. Open the workflow and click Activity in the top navigation.
  2. Each run entry shows the trigger payload (for inbound) or the HTTP response (for outbound), along with timestamps and status codes.
Retrying failed deliveries For outbound webhooks, if a request fails (non-2xx response or timeout), RCB Automation retries with exponential backoff — once after 1 minute, then 5 minutes, then 30 minutes. After three failed attempts, the run is marked as Failed and no further retries occur. To manually retry a failed outbound request:
  1. Go to Activity and find the failed run.
  2. Click the run to expand it, then click Retry step.
Manual retries re-execute the entire workflow step using the original payload data. If the downstream service is still unavailable, the retry will also fail.