How to Receive Webhooks in WordPress Without Zapier
You can receive webhooks in WordPress without Zapier using Krom Automation Pro‘s incoming webhook receiver. You get a unique secret URL per workflow, HMAC-SHA256 signature verification, and a field mapping system that pipes any payload value into a WordPress action.
The incoming webhook receiver is a Pro feature, so you need a paid plan. Free plans start at $69 a year or $199 as a one-time lifetime payment.
Most guides on this topic focus on sending data out of WordPress to Zapier or Make. That is the wrong direction if your problem is a third-party service pushing data to your site. Stripe needs to tell your site when a payment clears.
GitHub needs to tell your site when a pull request merges. Those services send POST requests to a URL you control, and your site needs to be listening at that URL, verifying the request is genuine, and acting on the data.
This guide covers exactly that: how to set up a secure inbound webhook endpoint in WordPress, how to map payload fields to merge tags, and how to wire the whole thing to real WordPress actions without a third-party automation service sitting in the middle. Browse the full feature list to see everything Krom Automation covers beyond webhooks.
What Is an Incoming Webhook and Why Does WordPress Struggle With It?
An incoming webhook is a POST request sent by an external service to a URL your application exposes. The external service initiates the call.
Your application receives it, parses the payload, verifies the signature, and acts on the data. This is the opposite of polling, where your app repeatedly asks an external service whether anything changed.
WordPress does not expose any built-in endpoint for this. Out of the box, if Stripe fires a payment_intent.succeeded event, there is nowhere on a WordPress site for that request to land.
You can build a custom REST endpoint in PHP, but that means writing and maintaining a request handler, signature verification logic, a retry queue, and logging. That is a meaningful amount of code for what is conceptually a simple operation.
The other common answer is Zapier: receive the webhook on Zapier’s servers, then have Zapier call a WordPress action via a plugin. That works, but it adds a third-party dependency, a per-task cost, and a data routing path that takes your webhook payload outside your server before it ever touches your site. For payment data or PII, that routing matters.
What the Krom Automation Incoming Webhook Receiver Actually Does
The incoming webhook receiver in Krom Automation Pro gives every workflow its own unique URL under your domain. That URL is a WordPress REST API endpoint registered under the krom-automation/v1 namespace. When an external service sends a POST request to it, Krom Automation receives the payload, runs 9 security checks, and fires the workflow if everything passes.
The security layer includes HMAC-SHA256 signature verification. You configure the shared secret inside the workflow settings. When a request arrives, Krom Automation recomputes the HMAC using the raw request body and your secret, then compares it against the signature header the sender included.
If they do not match, the request is rejected before any workflow logic runs. This is the same verification model Stripe, GitHub and Shopify all use on their outbound webhooks.
A webhook endpoint without signature verification is an open door. Any request that knows the URL can trigger your workflow. HMAC verification means only the service holding your shared secret can send valid requests.
Once the request passes verification, the payload fields are available as merge tags inside any action in the workflow. If Stripe sends a payload with a customer.email field, that value is accessible via a merge tag and can be passed into a Create User action, an Update Post Meta action, a Send Email action, or an HTTP Request to another service. The merge tags documentation covers the full syntax for accessing nested payload fields.
How to Set Up Your First Incoming Webhook Workflow
Setup follows four steps. Work through them in this order. Skipping to payload mapping before the URL is generated means you have nothing to give the external service to test against.
- Create a new workflow on the visual canvas and set the trigger to Incoming Webhook. Krom Automation generates a unique secret URL immediately. Copy it. This is the URL you register in Stripe, GitHub, or whichever service is sending.
- Configure HMAC verification in the trigger settings. Paste the shared secret your external service provides, or generate a secret here and paste it into the external service. Set the header name Krom Automation should read the signature from (for Stripe this is
Stripe-Signature, for GitHub it isX-Hub-Signature-256). - Send a test payload from the external service’s dashboard. Most platforms, including Stripe and GitHub, have a “send test event” button in their webhook configuration screen. Krom Automation logs the incoming request in the execution history whether it succeeds or fails, so you can inspect the full payload structure.
- Map payload fields to actions using merge tags. Once you have seen a real payload in the logs, you know exactly what fields exist and how they are nested. Use those field paths in your action configuration.
The step-by-step workflow builder guide covers the canvas interface in detail if this is your first workflow. The workflow simulator lets you run a dry test with zero side effects before you point a live Stripe account at your endpoint.
Stripe Webhook Example: Create a WordPress User on Payment
Stripe fires a payment_intent.succeeded event when a payment completes. The payload includes the customer’s email address, the amount, the currency, and a metadata object you can populate with anything you like when creating the payment intent on your frontend.
A practical workflow for a digital product site:
- Trigger: Incoming Webhook (Stripe endpoint, HMAC verified against your Stripe signing secret)
- Condition: Check that
data.object.statusequalssucceededbefore proceeding - Action 1: Create User, with email pulled from the merge tag for
data.object.receipt_email - Action 2: Send Email to the new user with their login details, using the visual email builder to design the template
- Action 3: Update Post Meta on a licence post to mark it as active, with the user ID from the Create User step injected as the meta value
The whole workflow runs on your server. The Stripe payload never leaves your hosting environment.
If you have a MemberPress membership or Easy Digital Downloads setup, you would typically handle payment events through those plugins’ own triggers rather than raw Stripe webhooks. But for a custom or headless payment flow, the incoming webhook receiver is the right tool.
GitHub Webhook Example: Trigger a WordPress Action on Pull Request Merge
GitHub fires a pull_request event when a PR is opened, updated, or merged. The payload includes the repository name, the PR title, the author, and an action field that tells you whether this is an open, synchronize, or closed event. When action is closed and pull_request.merged is true, the PR was merged.
A practical workflow for a development team that uses WordPress as an internal dashboard:
- Trigger: Incoming Webhook (GitHub endpoint, HMAC verified against your GitHub webhook secret)
- Condition: Branch on
actionequalsclosedANDpull_request.mergedequalstrue - Action: Create Post with the PR title as the post title, the author and repository as meta fields, and status set to Published in a custom post type you use for deployment tracking
You can extend this with a Slack notification using the Slack integration, so your team gets a message in your deployment channel every time a merge lands. Conditions and branching are covered in the conditions and branching documentation if you need to handle multiple event types from the same endpoint.
The most useful webhook workflows are the boring ones: a payment clears, a user record appears. No manual step, no CSV import, no “did that actually run?” in the execution log.
What Gets Logged and What Happens When a Webhook Fails
Every incoming webhook request creates an execution record. The log shows the full raw payload, which step succeeded, which step failed, and the error message if one was thrown. For debugging a misconfigured payload mapping or a signature mismatch, the execution log is the first place to look, not your server’s error log.
Failed executions trigger an email notification to the address you configure in Krom Automation settings. The retry system uses configurable backoff, so a temporary failure on your side does not silently drop the event. The analytics dashboard shows total executions, success rate, and a trend chart, so a spike in failures across your webhook workflows is visible without digging through individual logs.
One real constraint worth naming: Krom Automation uses Action Scheduler for background execution. On very low-traffic sites where nothing visits for hours at a time, WP-Cron fires late, which means delayed actions in a workflow may not run on schedule. The incoming webhook itself receives and logs the payload immediately when the request arrives.
Delays you add to subsequent actions in the workflow are what depend on cron timing. If you are running a high-volume webhook integration, configure a real server cron to trigger WP-Cron on a fixed interval, typically every minute.
Incoming Webhook vs. HTTP Request Action: What Is the Difference?
Krom Automation has two webhook-related features and they serve opposite directions. Understanding which one you need saves time.
| Feature | Direction | When to use it | Plan required |
|---|---|---|---|
| Incoming Webhook Receiver | External service sends data TO your WordPress site | Stripe payment events, GitHub pushes, Shopify order hooks, any third-party push notification | Pro |
| HTTP Request Action | Your WordPress site sends data TO an external service | Posting form data to a CRM, calling a custom API, triggering a remote build | Free |
The HTTP Request action supports GET, POST, PUT, PATCH and DELETE with JSON response parsing and is available in the free plugin. If you want to send form submission data to an external endpoint when someone fills in a Gravity Forms or WPForms form, the HTTP Request action covers that without a Pro plan.
What Does This Cost Compared to Routing Through Zapier?
The cost comparison changes significantly depending on volume. Zapier’s Professional plan runs around $240 a year billed annually for 750 tasks a month, as of September 2026, and it uses per-task billing.
A single webhook that triggers three actions counts as three tasks. At 500 payment webhooks a month with three actions each, that is 1,500 tasks, which pushes you past the 750-task limit on the base plan.
| Scenario | Krom Automation Pro (1 site, annual) | Zapier Professional (annual) |
|---|---|---|
| 500 webhook events/month, 3 actions each | $69/year, no task limit | ~$240/year, requires plan upgrade above 750 tasks/month |
| 2,000 webhook events/month, 3 actions each | $69/year, no task limit | Higher tier required, task billing increases cost |
| Data routing | Stays on your server | Passes through Zapier’s servers |
| Signature verification | Built in, HMAC-SHA256 | Requires manual webhook step configuration |
| Lifetime option | $199 one payment | Not available |
Krom Automation Pro has no per-task billing at any tier. Every plan includes every Pro feature and all 25 integrations. The only variable between plans is the number of sites: 1 site on Basic, 5 sites on Standard, and unlimited sites on Enterprise.
For an agency running webhook integrations across multiple client sites, the Standard plan at $149 a year covers all 5 sites with no additional per-site or per-execution cost. See full pricing details.
Per-task billing turns a high-volume webhook integration into an unpredictable monthly expense. A flat annual plan does not.
What Krom Automation Does Not Cover
Being honest about limits is more useful than overselling. Krom Automation is WordPress-native.
At least one end of every workflow, the trigger or the action, needs to touch your WordPress site. If you need to receive a webhook from Stripe and forward the data to HubSpot with no WordPress involvement at all, a general-purpose automation platform is the better tool for that specific flow.
The incoming webhook receiver does not currently support XML payloads natively. Most modern services send JSON, but some legacy systems, particularly SOAP-based APIs, send XML. If your external service sends XML, you would need a middleware step to convert it before it reaches Krom Automation.
Testing on a local development site requires a publicly accessible URL. Your local localhost:8080 address is not reachable by Stripe or GitHub. Tools like ngrok or Expose can tunnel a public URL to your local server for testing.
Once the workflow is working locally, move it to a staging or production environment before pointing a live Stripe account at it. The workflow simulator handles some of this by letting you run logic dry without a real incoming request, but you still need a public URL for end-to-end testing with the external service.
Also from wpRigel
Pollify is wpRigel’s Gutenberg-native poll, survey and quiz plugin. Polls are built as real blocks inside the block editor, so there are no shortcodes to paste and no separate interface to configure. Pro adds NPS voting, CSV and PDF export, IP blocking, and enriched analytics.
Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K to jump anywhere, search posts, pages, users and products, and run admin actions without clicking through menus. It is the only WordPress command palette with genuine WooCommerce depth: search orders by customer name or email, update stock, change order status, and email customers, all from the keyboard.
Frequently Asked Questions
Does receiving webhooks in WordPress require writing custom PHP?
Not with Krom Automation Pro. The incoming webhook receiver creates a REST endpoint automatically when you add the trigger to a workflow.
You configure the shared secret and header name in the workflow settings, and the signature verification runs without any code. Custom PHP is only needed if you build the endpoint from scratch without a plugin.
Can I use one webhook URL to receive multiple event types from Stripe?
Yes. Krom Automation receives the full raw payload regardless of event type. Use a condition node in your workflow to branch on the type field in the Stripe payload.
Point the Yes path at one set of actions for payment_intent.succeeded and the No path at a different set for customer.subscription.deleted. The conditions and branching documentation shows how to set up multi-path logic.
Is the incoming webhook URL permanent, or does it change?
The URL is tied to the workflow and does not change unless you delete and recreate the workflow. You can safely register it in Stripe, GitHub or any external service and leave it there. If you duplicate a workflow, the duplicate gets its own unique URL.
What happens if Stripe retries a webhook my site already processed?
Krom Automation logs every execution. The “run once per entity” enforcement prevents the same trigger event from executing a workflow more than once for the same entity. For webhook payloads, you can also add a condition that checks a post meta or user meta field before allowing the workflow to proceed, so a duplicate Stripe retry does not create a second user or a second licence record.
Can I receive webhooks on the free version of Krom Automation?
The incoming webhook receiver is a Pro feature. The free version includes an HTTP Request action for sending data outbound, 16 triggers for native WordPress events, and 21 actions.
The free vs Pro comparison lists exactly what is available at each tier. The free plugin is available on the WordPress.org plugin directory with no trial period and no run caps.
How do I test a webhook workflow before pointing a live service at it?
Use the workflow simulator for dry runs with zero side effects. For end-to-end testing with the actual external service, you need a publicly accessible URL.
On a local site, tools like ngrok create a temporary tunnel. Most services including Stripe also let you send test events from their dashboard, which is the safest way to verify the signature check is working before you go live.
Krom Automation Pro starts at $69 a year or $199 as a one-time lifetime payment, with a 14-day money-back guarantee on every plan. Compare all three plans to find the right fit for your site count.