Webhooks

The On Webhook trigger starts your pattern when an HTTP request arrives at the pattern's unique webhook URL. This is the most common trigger for event-driven automation — connecting DRAGOPS to services like GitHub, Slack, Stripe, PagerDuty, and any system that sends HTTP callbacks.

How webhook URLs work

Every pattern with an On Webhook trigger gets a unique webhook URL. This URL has two important properties:

• Pre-deployment availability. The URL is assigned when you create the pattern, not when you deploy it. You can register it with an external service immediately, even before you finish building the pattern.
• Stability across deploys. The URL never changes. When you undeploy and redeploy a pattern, the URL remains the same. You do not need to update integrations after redeployment.

This means you can set up your GitHub webhook, configure your Stripe endpoint, or register your Slack command URL once and never touch it again.

URL structure

Webhook URLs follow this format:

https://your-dragops-instance/api/webhooks/{pattern-id}

Each URL is unique to a single pattern. You can find the URL on the Triggers page in the dashboard or in the deployment detail view.

Supported HTTP methods

On Webhook accepts requests using any of these HTTP methods:

• GET
• POST
• PUT
• PATCH
• DELETE

The HTTP method used by the caller is available as an output pin on the trigger node, so your pattern can branch logic based on the method if needed.

Output pins

The On Webhook node provides four output pins that give your pattern access to the full incoming request:

Wire these pins to downstream nodes to extract and process the incoming data. For example, connect the Body pin to a Get Property node to pull a specific field from the payload.

HMAC signature validation

Many services sign their webhook payloads with an HMAC signature so you can verify the request is authentic. The signature is typically sent in a header like X-Hub-Signature-256 (GitHub) or Stripe-Signature (Stripe).

To validate signatures in your pattern:

1. Use a Get Property node to extract the signature header from the Headers output pin.
2. Use an HMAC node to compute the expected signature from the raw request body and your shared secret.
3. Compare the computed signature against the received signature using a Compare node.
4. Use a Branch node to reject requests with invalid signatures.

This ensures your pattern only processes requests that originate from the expected service.

Custom responses with Respond To Webhook

By default, DRAGOPS returns a 200 OK response to the caller immediately when a webhook request arrives. If you need to return custom data, a specific status code, or custom headers, use the Respond To Webhook node.

The Respond To Webhook node accepts three input pins:

Place the Respond To Webhook node at the point in your execution flow where you want to send the response. Any nodes that execute after Respond To Webhook continue running, but the caller has already received the response.

Example: acknowledge and process

A common pattern is to acknowledge the webhook immediately and then do the heavy processing:

1. On Webhook fires.
2. Respond To Webhook sends a 200 with {"status": "accepted"}.
3. Downstream nodes process the payload, call APIs, and log results.

This keeps the caller's connection short and prevents timeout errors from slow processing.

Tap mode

Tap mode lets you capture a real webhook payload in the editor without deploying your pattern. Instead of writing sample JSON by hand, you send a live request and DRAGOPS captures the exact data your integration sends.

How to use tap mode

1. Open your pattern in the editor.
2. Select Run in the toolbar, then select Listen for Test Event.
3. The editor displays a temporary webhook URL and begins listening.
4. Send a request to the displayed URL from your external service, a browser, or a command-line tool.
5. The incoming payload appears in the test dialog, pre-filled and ready to use.

curl -X POST https://your-tap-url \
  -H "Content-Type: application/json" \
  -d '{"event": "push", "repository": "my-repo"}'

Tap mode listens for a limited time and accepts a single request. After the payload is captured, the temporary URL stops accepting requests. You can start a new tap session at any time.

Why tap mode matters

• Accurate test data. Real payloads from real services contain fields, nesting, and edge cases that are easy to miss when writing sample JSON by hand.
• Faster iteration. Capture a payload, run a test, adjust your pattern, and capture again — all without leaving the editor or deploying.
• Pre-deployment validation. Verify that your pattern handles real data correctly before it goes live.

Debugging webhook delivery

If your webhook is not triggering as expected, check these common issues:

The pattern is not deployed

Webhook URLs are assigned at creation, but the execution engine only processes incoming requests when the pattern is deployed. Verify that your pattern shows an active deployment on the dashboard.

The request body is not JSON

DRAGOPS parses the request body as JSON. If the sender uses application/x-www-form-urlencoded or plain text, the Body pin may be empty or contain unexpected data. Check the Content-Type header the sender uses.

The external service has an outdated URL

Although DRAGOPS webhook URLs are stable, verify that the external service has the correct URL registered. Copy the URL from the Triggers page and compare it to the service's webhook configuration.

The request timed out

If your pattern takes a long time to process and does not use Respond To Webhook, some senders may time out waiting for a response. Use Respond To Webhook early in the flow to acknowledge receipt, then process the payload afterward.

Best practices

• Validate payloads. Always verify the structure of incoming data before processing it. Use Branch nodes to handle missing or unexpected fields gracefully.
• Verify signatures. If the sending service supports HMAC signatures, validate them. This prevents unauthorized requests from triggering your pattern.
• Respond quickly. Use the Respond To Webhook node to send an immediate acknowledgment, especially for patterns with slow downstream processing.
• Handle idempotency. Some services retry webhook delivery if they do not receive a timely response. Design your pattern to handle duplicate deliveries safely — for example, by checking a unique event ID before processing.
• Log incoming data. Add a Log node early in the flow to capture incoming payloads. This makes debugging much easier when something goes wrong.

Related

• Triggers overview -- comparison of all trigger types
• Schedules -- time-based triggers with cron expressions
• Pattern calls -- invoke patterns from other patterns
• Test and debug -- tap mode, data pinning, and console output
• Deployments -- deploying patterns to activate triggers