DRAGOPS
DRAGOPS
DocumentationTroubleshootingWebhook issues

Webhook issues

Fix webhook delivery failures — 404 errors, empty payloads, HMAC failures, timeouts, and tap mode.

Webhook issues fall into two categories: delivery problems (the request never reaches your pattern) and processing problems (the request arrives but the pattern does not handle it correctly). This page covers both.

Webhook URL returns 404

Symptom

When you send a request to your webhook URL, you receive a 404 Not Found response.

Cause

The pattern is not deployed. Webhook URLs are assigned when you create the pattern, but the execution engine only processes incoming requests when the pattern has an active deployment. An undeployed pattern's webhook URL returns 404.

Solution

  1. Open the DRAGOPS dashboard and go to the Deployments page.
  2. Check whether your pattern has an active deployment. If it does not, open the pattern in the editor and select Deploy.
  3. After deployment, send the request again. The webhook URL is the same — it does not change across deploy and undeploy cycles.

If the pattern is deployed and you still receive a 404, verify you are using the correct URL. Copy the URL directly from the Triggers page or the deployment detail view and compare it to what the external service has configured.

Webhook does not trigger the pattern

Symptom

You send a request to the webhook URL and receive a 202 Accepted response, but no execution appears in the deployment's execution history.

Cause

Several things can prevent the execution from running even though the request was accepted:

  • The deployment is paused
  • The request was a duplicate and was filtered by the idempotency check
  • The request was rate-limited

Solution

  1. Check deployment status. Go to the Deployments page and verify the deployment is in the Active state, not Paused. If paused, select Resume.

  2. Check for idempotency filtering. If the external service sends the same request multiple times (using the same idempotency key), DRAGOPS only processes the first one. Verify the sender is not retrying with the same payload.

  3. Check the request log. Go to the Triggers page, find the webhook, and open the Request Log tab. This shows every incoming request — including rejected ones — with the status and reason. Look for entries with a rejection status to understand why the request was not processed.

  4. Verify the URL is correct. If you have multiple On Webhook nodes in the same pattern, each one has its own unique URL. Make sure the external service sends to the correct URL for the trigger you expect to fire.

Request body is empty

Symptom

The On Webhook node's Body output pin returns an empty object {}, even though the external service sends a payload.

Cause

DRAGOPS parses the request body as JSON. If the sender does not set the Content-Type header to application/json, the body may not be parsed correctly. Common misconfigurations include:

  • The sender uses application/x-www-form-urlencoded (common with HTML forms)
  • The sender uses text/plain
  • The sender omits the Content-Type header entirely

Solution

  1. Check the sender's Content-Type header. The sender must include Content-Type: application/json in the request headers.

  2. Update the sender configuration. In the external service's webhook settings, ensure the payload format is set to JSON and the Content-Type header is configured correctly.

  3. Test with curl. Send a test request with the correct header to verify DRAGOPS receives the body:

curl -X POST https://your-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"test": "data"}'
  1. Check the Headers output pin. Wire the On Webhook node's Headers pin to a Log node and run a test. Inspect the content-type header value in the log output to see what the sender is actually sending.

HMAC validation fails

Symptom

Requests to the webhook are rejected with an HMAC validation error. The external service reports that the webhook delivery failed.

Cause

The HMAC secret configured in DRAGOPS does not match the secret configured in the external service. HMAC validation computes a hash of the request body using a shared secret — if either side uses a different secret, the signatures do not match.

Other possible causes:

  • The signature algorithm does not match (for example, SHA-256 vs SHA-1)
  • The request body was modified in transit (by a proxy or middleware)
  • The secret contains leading or trailing whitespace

Solution

  1. Verify the shared secret. Compare the HMAC secret configured in your DRAGOPS webhook with the one configured in the external service. They must be identical, including case and whitespace.

  2. Check the algorithm. Make sure both sides use the same hashing algorithm. GitHub uses SHA-256 (X-Hub-Signature-256), while some older integrations use SHA-1.

  3. Trim whitespace. Copy the secret from the external service and paste it fresh into the DRAGOPS webhook configuration. Avoid manual typing, which can introduce invisible characters.

  4. Check for payload transformation. If the request passes through a proxy, API gateway, or middleware before reaching DRAGOPS, verify that nothing modifies the request body. Any change to the body — even adding or removing whitespace — invalidates the HMAC signature.

Webhook times out

Symptom

The external service reports a timeout or delivery failure for the webhook. The execution may or may not appear in the history, and the service may retry the delivery.

Cause

The pattern takes too long to execute. When a webhook request arrives, DRAGOPS processes it and holds the HTTP connection open until the pattern completes (unless the pattern uses Respond To Webhook). If the pattern takes longer than the caller's timeout window, the caller gives up and may retry.

Solution

  1. Use Respond To Webhook early. Add a Respond To Webhook node near the beginning of your execution flow. This sends a response to the caller immediately (for example, 200 OK with {"status": "accepted"}), and the rest of the pattern continues processing without holding the connection open.

  1. Identify the slow node. Check the execution log for timing information. If an HTTP Request or Call Pattern node takes several seconds, it is likely causing the caller to time out.

  2. Break into sub-patterns. Move slow processing into a separate pattern and invoke it with Call Pattern. The webhook-triggered pattern acknowledges the request quickly, and the sub-pattern handles the heavy work.

Duplicate executions

Symptom

The same webhook event triggers the pattern more than once. The execution history shows multiple runs with identical or near-identical input data.

Cause

Many external services retry webhook delivery if they do not receive a timely response. If your pattern takes a long time to process and does not use Respond To Webhook, the external service may assume the delivery failed and send the same request again.

Solution

  1. Respond quickly. Use Respond To Webhook early in the flow to send an immediate acknowledgment. This tells the external service that the delivery succeeded, preventing retries.

  2. Implement idempotency checks. If the external service includes a unique event ID in the payload (for example, GitHub's X-GitHub-Delivery header or Stripe's event.id), extract this ID early in the pattern and check whether you have already processed it. Use a variable or external store to track processed event IDs.

  3. Configure the sender's retry behavior. Some services let you configure the retry interval or disable retries entirely. Check the external service's webhook settings.

Tap mode does not receive payloads

Symptom

You start a tap mode session in the editor, send a request to the displayed URL, but no payload appears in the test dialog.

Cause

Tap mode listens for incoming requests for a limited time. If the request arrives outside the listening window, or if the request is sent to the wrong URL, the payload is not captured.

Solution

  1. Check the URL. Copy the tap mode URL directly from the editor dialog and paste it into your tool or service. Do not type it manually — tap URLs are temporary and unique to each session.

  2. Send the request promptly. Tap mode has a limited listening window. Start the listening session, then send the request within a few seconds.

  3. Verify the request format. Send a JSON payload with the Content-Type: application/json header. Tap mode captures the request body in the same way as a live webhook.

  4. Start a new session. If the listening window expired, select Listen for Test Event again to start a fresh tap session with a new URL.

  5. Check network connectivity. Make sure the machine or service sending the request can reach the DRAGOPS instance. If you are testing locally, verify that the URL is accessible from your network.

Execution errors

Diagnose and fix common execution failures — wrong data types, timeouts, infinite loops, and silent errors.

Deployment issues

Fix deployment failures — compilation errors, unresponsive patterns, and redeployment problems.

On this page

Webhook URL returns 404SymptomCauseSolutionWebhook does not trigger the patternSymptomCauseSolutionRequest body is emptySymptomCauseSolutionHMAC validation failsSymptomCauseSolutionWebhook times outSymptomCauseSolutionDuplicate executionsSymptomCauseSolutionTap mode does not receive payloadsSymptomCauseSolutionRelated