Activepieces Triggers Not Firing: Webhook Fix Guide

May 13, 2026 · Editorial Team · 6 min read · activepieces troubleshooting error-fix

You're a no-code builder who set up an Activepieces flow to catch incoming Typeform submissions via webhook, pass the data to a Claude AI step for lead scoring, and push the scored result to a Notion database. You tested it during setup, it worked, you turned it on. Two days later your Notion database hasn't received a single new record, and you can see new Typeform submissions in Typeform's own dashboard. The Activepieces flow run history is completely blank. No failed runs, no successful runs. The trigger is just not firing. Here's a systematic approach to find out why and fix it.

What this error actually means

In Activepieces 0.30 and later, webhook-triggered flows depend on a registered webhook URL that Activepieces creates when you activate the flow. When someone submits a form or your source app fires an event, it sends an HTTP POST to that URL. Activepieces receives it, creates a flow run, and processes the steps. When triggers don't fire at all, with zero entries in the run history, it means either the webhook URL isn't receiving requests, the requests are being received but silently dropped, or the flow isn't in an active state to process them.

Quick fix (when you need it working in 60 seconds)

Open the flow in Activepieces and check the status indicator in the top right corner. Confirm it shows "Active" (green dot), not "Draft" or "Inactive."
Click the trigger step and find the webhook URL. It looks like https://cloud.activepieces.com/api/v1/webhooks/[flow-id]. Copy it.
Open a tool like Postman or use curl -X POST [your-webhook-url] -H "Content-Type: application/json" -d '{"test": "data"}' to send a test request directly to the URL.
Check the Activepieces run history immediately after the test POST. If a run appears, the flow is working and the problem is on the source app's side (Typeform is sending to the wrong URL or not sending at all).
If no run appears after the manual POST, the issue is on Activepieces' side, and you need to continue with the steps below.

Why this happens

The most common cause for a webhook trigger that worked once but stopped is that Activepieces regenerates the webhook URL when you edit and re-save a flow while it's active. The new URL is different from the old one. Your source app (Typeform, in this example) still has the old URL registered. Requests are going to the old URL, which no longer exists or is no longer associated with your flow. Activepieces doesn't notify you that the URL changed.

This URL regeneration happens more often than users expect. Any time you open an active flow in edit mode and save it, even if you change nothing, Activepieces may generate a new webhook endpoint. This is a known behavior in Activepieces versions up to 0.30 and has been partially addressed in 0.31's beta, but it still occurs in certain edit scenarios.

A second cause is network-level blocking in self-hosted Activepieces deployments. If you're running Activepieces on your own server, the webhook URL is your server's address. If your server sits behind a firewall or NAT without a public IP, external services like Typeform can't reach it. The source app fires the webhook, it never arrives, and Activepieces never knows a request was attempted.

For Activepieces Cloud users, the cloud infrastructure itself can occasionally drop webhook requests during high-load periods. These are rare but have been reported on the Activepieces GitHub issues page. The drop is silent, with no error in the run history.

Finally, some source apps have a retry window. If Typeform's webhook registration failed the first time it tried to verify your URL (during the initial setup ping), Typeform may have silently disabled the webhook endpoint and stopped sending requests. Typeform shows webhook delivery status in its own dashboard under Integrations > Webhooks, and that's the first place to check.

Permanent fix

Deactivate the flow in Activepieces, then reactivate it. Go to the flow editor, click the "Deactivate" button, wait five seconds, then click "Activate." This generates a clean webhook URL in the current state of your flow.
After reactivating, copy the new webhook URL from the trigger step configuration immediately. Do not edit the flow again before registering the URL in your source app.
Go to Typeform (or whichever source app you're using). Delete the existing webhook and create a new one using the fresh URL from step 2. Enable webhook retries in Typeform's settings and set the retry attempts to at least 3.
Send a test submission through Typeform and verify the flow run appears in Activepieces' run history within 30 seconds.
For self-hosted Activepieces instances: ensure your instance's URL is publicly accessible. Run curl -I https://your-instance.com/api/v1/webhooks/test from outside your network to verify. If you get a connection refused error, configure your firewall or reverse proxy (nginx/Caddy) to allow inbound traffic on port 443.
Enable webhook logging in Activepieces. Go to Settings > Logs and turn on "Log all incoming webhook requests." This creates a raw request log that shows you every incoming POST, whether or not it triggered a flow run. This is invaluable for diagnosing future issues.
Add a test step to the beginning of your flow that immediately writes the incoming payload to a simple data store or sends a Slack notification. This acts as a flow "heartbeat" and tells you within seconds whether the trigger is firing, even if later steps fail.
For critical production flows, set up a Cronitor or UptimeRobot monitor that sends a daily test webhook to your flow URL. If the flow run doesn't appear, you get an alert. This catches URL rotation issues before they cause multi-day gaps.

Prevention

Never edit an active flow unless you plan to also update the webhook URL in your source app immediately after. The safest workflow is to deactivate, make your edits, reactivate, copy the new URL, and update the source app, all in one session. If you must edit a live flow without touching the trigger, be aware that the URL may change and have your source app's webhook settings open in another tab ready to update.

Document your webhook URLs in a shared sheet or Notion page with the date they were registered. When an Activepieces URL rotates, having the old URL documented helps you confirm whether your source app is sending to a stale endpoint.

Check your source app's webhook delivery log regularly, not just Activepieces' run history. Typeform, Stripe, GitHub, and most other webhook sources keep their own delivery logs with HTTP response codes. A log full of 404 or 500 responses tells you exactly when the connection broke.

When the fix doesn't work

If the manual curl test POST to the webhook URL succeeds (Activepieces shows a run) but Typeform sends are never received, the issue is 100% on Typeform's end. Check Typeform's webhook delivery history and re-register the webhook from scratch. Some Typeform plans have webhook delivery rate limits that silently drop excess requests.

For self-hosted instances where the webhook URL is unreachable from the public internet, consider deploying an ngrok or Cloudflare Tunnel as a temporary bridge while you sort out your network configuration. Cloudflare Tunnel (cloudflared tunnel) is free and routes external traffic to your internal Activepieces instance without exposing your server's IP.

If the issue is intermittent (some triggers fire, some don't), open a bug report on the Activepieces GitHub at github.com/activepieces/activepieces/issues. Include your version number, your hosting environment, and the time range of the dropped webhooks. The team is responsive and intermittent webhook drops are usually infrastructure bugs they want to know about.