Webhooks Explained Without the Jargon (For WordPress Users)

A webhook in WordPress is an automatic notification your site sends or receives the moment a specific event happens. A user registers, an order is placed, a form is submitted, and instead of waiting for something to check in, WordPress fires a message straight to wherever you tell it.

No polling, no manual intervention, no delay. That is the entire concept.

Most explanations of webhooks get technical fast. This one will not. By the end you will know what a webhook actually is, how it differs from a regular API call, why the inbound versus outbound distinction matters more than most guides admit, and how to use webhooks on your WordPress site without touching a line of code.

We will also cover the security and debugging gaps that almost every other explanation skips entirely, because those are the questions that come up the moment a webhook stops working.

Browse the full Krom Automation feature list to see how WordPress-native automation handles webhooks alongside 16 triggers, 21 actions, and a visual drag-and-drop canvas.

What a Webhook Actually Is (The Short Version)

Think about how you track a parcel. The old way is to visit the courier’s website every few hours and check.

The modern way is to give them your email address and get notified the moment the status changes. Webhooks are the modern way for software.

Without a webhook, one application has to keep asking another “has anything changed?” That repeated asking is called polling, and it wastes resources on both ends. A webhook flips the model. Instead of asking, the first application says “when something changes, send a message to this URL.” The message arrives in milliseconds, not on the next polling cycle.

A webhook is not a feature you configure once and forget. It is a live connection between two pieces of software, and it breaks the moment either end changes without telling the other.

In WordPress terms, the event might be a WooCommerce order completing, a contact form submitting, or a new member registering. The destination might be Slack, Mailchimp, a CRM, or another WordPress site entirely. The webhook is the pipe that carries the news from one to the other.

Outbound vs. Inbound Webhooks: The Distinction That Actually Matters

Most explanations treat webhooks as one thing. They are not. There are two directions, and mixing them up is why people end up configuring the wrong thing.

Outbound Webhooks: WordPress Sends the Message

An outbound webhook fires from your WordPress site to an external service. Something happens on your site, and WordPress pushes data to a URL you specify.

WooCommerce has built-in outbound webhook support. When an order is completed, WooCommerce can POST the order data to Zapier, Make, or any other endpoint listening for it.

Common outbound use cases:

• Sending a new order’s customer data to your CRM the moment it completes
• Posting a Slack message when a new member signs up
• Triggering a Mailchimp tag update when a user’s role changes
• Notifying a fulfilment service when a digital product is purchased

Inbound Webhooks: WordPress Receives the Message

An inbound webhook works in reverse. An external service sends a payload to a URL on your WordPress site, and your site does something with it. This requires your WordPress site to expose a URL that can receive and process the incoming data.

WordPress does not do this natively. You need a plugin that creates that receiver endpoint for you.

Common inbound use cases:

• A payment processor notifying your site that a subscription renewed
• A third-party form tool sending submissions into your WordPress database
• Zapier or Make pushing data back into WordPress after processing it elsewhere
• A calendar or booking system updating a WordPress post when an appointment is confirmed

The reason this distinction matters: if you need to send data out, you configure a webhook URL in WordPress and point it at the external service. If you need to receive data in, you need to generate a receiver URL in WordPress and give it to the external service. These are opposite setups and opposite plugins handle them.

Webhooks vs. the REST API: What Is the Actual Difference?

WordPress has a full REST API, and it confuses people who are trying to understand webhooks. The difference is simpler than it sounds.

Question	REST API	Webhook
Who starts the conversation?	The requesting service asks WordPress	WordPress (or the external service) notifies the other party
When does data move?	Only when someone makes a request	The moment a trigger event fires
Does it require repeated polling?	Yes, if you want near-real-time updates	No, the event itself triggers the message
Do you need an endpoint on your site?	WordPress provides one by default	Only for inbound webhooks
Typical use	Reading or writing data on demand	Reacting to events automatically

The REST API is a door you can knock on any time. A webhook is a doorbell that rings automatically. Both move data, but the trigger and timing are completely different.

Do You Need a Plugin to Use Webhooks in WordPress?

For outbound webhooks, it depends on the plugin you already have. WooCommerce includes outbound webhook support in its core settings under WooCommerce Settings Advanced Webhooks.

You can create a webhook there, paste in a destination URL, and choose which events trigger it. No additional plugin required for that specific case.

For everything else, yes, you need a plugin. WordPress core does not include a webhook sender or receiver. Plugins like Krom Automation’s incoming webhook receiver generate a unique secret URL per workflow, so any external service can push data into a WordPress automation without you writing a single line of PHP.

If you want to connect a form like WPForms or Gravity Forms to an external service via webhook, the form plugin may have its own webhook add-on, or you can route the submission through an automation plugin. Our documentation covers how to do this for WPForms and Gravity Forms specifically.

What a Webhook URL Is and What You Put There

A webhook URL is just a web address that listens for incoming HTTP requests. When you configure an outbound webhook in WooCommerce or a form plugin, you paste in the destination URL, which is usually provided by the receiving service. Zapier gives you a URL.

Make gives you a URL. Slack gives you a URL. You copy it and paste it into the WordPress setting.

When you set up an inbound webhook, the process reverses. The plugin generates a URL on your site, and you copy that URL into the external service’s webhook configuration. Krom Automation Pro generates one unique secret URL per workflow, so you are never reusing the same endpoint for multiple unrelated sources.

The URL itself looks like any other web address. What matters is what happens when data arrives at it.

A good webhook receiver validates the incoming payload, processes it, and executes whatever action is configured. A bad one accepts anything from anywhere, which is the security problem we cover next.

Most WordPress webhook tutorials show you where to paste the URL. Almost none of them tell you what to do when spoofed requests start arriving at that endpoint.

Webhook Security: What Nobody Else Explains

This is the section most webhook guides skip, and skipping it is a genuine mistake. An exposed webhook URL is a publicly reachable endpoint on your site.

Anyone who knows the URL can send data to it. Without verification, your site cannot tell the difference between a legitimate payload from Stripe and a fabricated one from someone trying to trigger your automation fraudulently.

How HMAC Signature Verification Works

The standard solution is HMAC-SHA256 signature verification. The sending service signs each payload with a shared secret key. When the payload arrives at your endpoint, you use the same secret to generate what the signature should be, then compare.

If they match, the payload is genuine. If they do not match, you reject it.

You do not implement this yourself. A well-built webhook receiver plugin handles it.

Krom Automation Pro’s incoming webhook receiver includes HMAC-SHA256 signature support alongside 9 additional security layers. When you configure the receiver, you paste in the shared secret the external service provides and the verification runs automatically on every incoming request.

Security checks worth confirming your webhook plugin performs:

• Signature verification using a shared secret, not just a URL token
• Rate limiting per source IP to prevent replay attacks
• Payload size limits so oversized requests cannot exhaust server memory
• Request logging so you can audit what arrived and when
• Rejection of duplicate payloads based on a unique event ID

If your current webhook setup does none of this, the endpoint is open to abuse. That is not a hypothetical risk. Payment processors and membership platforms specifically warn against accepting webhooks without signature verification.

When a Webhook Fails: Debugging Without a Developer

A webhook that fails silently is harder to diagnose than almost any other integration problem, because nothing visibly breaks on your site. The order goes through, the form submits, everything looks fine, and the CRM never got the update. Here is a structured approach to finding the problem.

Work Through This in Order

1. Check whether the event fired. If you are using an automation plugin, the execution log shows every trigger attempt. A missing entry means the trigger never fired, which points to a configuration problem on the sending side.
2. Check the HTTP response code. A successful delivery returns a 200 status. A 4xx response means the receiving URL rejected the request. A 5xx means the receiving server errored. A timeout means the receiver took longer than the sending service waited.
3. Check the payload format. Some services expect JSON. Some expect form-encoded data. Sending the wrong format results in a 400 error that looks like a network problem but is actually a data format mismatch.
4. Verify the URL is reachable. A webhook pointed at a localhost URL or a staging site behind HTTP authentication will never deliver. Test the URL from a public request tool first.
5. Check for duplicate deliveries. Some services retry on timeout. If your automation ran twice, the receiver got the payload but took too long to respond. Returning a 200 immediately and processing asynchronously solves this. Krom Automation handles background execution via Action Scheduler so the response goes back fast and processing happens separately.

Symptom	Most Likely Cause	Where to Check
No execution in the log	Trigger event never fired	Sending plugin settings, test the trigger manually
400 error on delivery	Wrong payload format or missing required field	Compare expected payload structure with what you are sending
401 or 403 error	Authentication failed or URL protected	Shared secret, HTTP auth on staging, IP allowlist
Timeout, no response code	Receiver too slow, or server unreachable	Use background processing, check hosting firewall rules
Automation ran twice	Retry after a slow 200 response	Enable run-once enforcement, return 200 before processing
Payload arrives, automation does nothing	Condition check failed or merge tag empty	Workflow conditions, merge tag configuration

How to Set Up Webhooks in WordPress Without Code

The practical setup depends on whether you are sending or receiving, and which plugins you are already using.

Sending a Webhook From WordPress

If the trigger lives in WordPress and you want to push data outward, you need the sending side configured. In Krom Automation, the free HTTP Request action handles this.

It supports GET, POST, PUT, PATCH and DELETE, accepts JSON payloads, and can parse the response for use in later steps. You drop it onto the canvas after any trigger, fill in the destination URL, and configure the body using merge tags to inject live event data like the user’s email address or the order total.

For example: a workflow that fires when an order completes, uses the HTTP Request action to POST the order data to your fulfilment API, then sends a confirmation email to the customer. The whole thing runs in the background so the customer’s checkout experience is not affected.

Receiving a Webhook Into WordPress

If the trigger lives outside WordPress and you want your site to react, you need an inbound receiver. Krom Automation Pro’s webhook receiver generates a unique secret URL per workflow.

You copy that URL, paste it into the external service’s webhook settings, configure the signature secret, and then build whatever automation you want to trigger on the WordPress side. No code, no custom endpoint, no PHP file to create.

If you want to automate based on form submissions specifically, Krom Automation has native integrations for Contact Form 7, Fluent Forms, Elementor Forms, and Ninja Forms. Native integrations are cleaner than routing through a webhook because the trigger is purpose-built for that plugin’s data structure.

A native form integration and an outbound webhook solve similar problems, but a native integration gives you structured field access without parsing raw JSON.

Real Examples: What WordPress Sites Actually Use Webhooks For

Concepts land better with concrete examples. Here are five realistic automation patterns that use webhooks, either sending or receiving.

• Stripe subscription renewed: Stripe sends an inbound webhook to WordPress. Krom Automation receives it, confirms the customer’s subscription status, and extends their membership access automatically. No manual renewal checks needed.
• WooCommerce order to fulfilment service: An order completes in WooCommerce, triggering an outbound webhook to a third-party warehouse. The warehouse receives product and shipping data, picks the order, and webhooks back a tracking number that WordPress then emails to the customer.
• Lead form to CRM: A visitor submits a contact form. Instead of relying on the form plugin’s native CRM integration (which may not exist), Krom Automation fires an HTTP Request to the CRM’s API, creating the contact and setting a pipeline stage, all within seconds of submission. Our guide on automating form lead follow-up walks through this pattern in detail.
• New member to Slack: A user upgrades to a paid membership. WordPress fires an outbound webhook to a Slack webhook URL, posting a message in your team’s #new-members channel. Takes about 4 minutes to configure and saves someone checking a dashboard manually every morning.
• External event system to WordPress calendar: A booking platform fires an inbound webhook when an appointment is confirmed. Krom Automation receives it, creates or updates a WordPress post with the appointment details, and sends a confirmation email to the customer from your WordPress domain.

What Breaks at Scale (What the Marketing Pages Leave Out)

Webhooks are excellent for event-driven automation. They are not the right tool for every situation, and there are failure modes worth knowing before you build something critical around them.

WordPress Cron dependency: Krom Automation runs automations via Action Scheduler in the background. On very low-traffic sites where no visitor arrives for hours, WP-Cron fires late.

If you need a webhook to trigger a time-sensitive action on a quiet site, configure a real server cron to run WP-Cron on a fixed schedule. Our article on whether automation plugins slow down WordPress covers this in more detail.

No guaranteed delivery: Most webhook senders retry on failure, but “most” is not “all”. If the receiving server is down for 30 minutes and the sender only retries twice, the payload is lost. For critical data, design your system to reconcile state periodically rather than relying purely on webhook delivery.

Order of delivery: Webhooks can arrive out of order. An “order updated” event can arrive before the “order created” event if the network routes them differently. If your automation logic assumes chronological order, build in a check.

Shared hosting firewall rules: Some shared hosts block outbound HTTP requests to non-standard ports or rate-limit them aggressively. An HTTP Request action that works on one host fails on another for a purely infrastructure reason. Test on the actual host before deploying anything production-critical.

Also from wpRigel

Pollify is a Gutenberg-native poll, survey and quiz plugin for WordPress. Polls are built directly inside the block editor as real blocks, so there are no shortcodes to paste and no separate admin interface to navigate. If you collect audience feedback or run quizzes, it fits into your editorial workflow without adding friction.

Commandify is a command palette for the WordPress admin. Press Cmd or Ctrl plus K to jump anywhere in the dashboard, search posts, users and orders, and run admin actions without clicking through menus. It is the only command palette plugin with genuine WooCommerce depth, covering orders, products, variations and customers as first-class commands.

Our Verdict on Webhooks in WordPress

Webhooks are one of the highest-leverage concepts a WordPress site owner can learn, because once you understand them, a large category of manual work becomes automatable. The outbound versus inbound distinction is the only conceptual hurdle. After that, the setup is mechanical.

If you are already using WooCommerce, outbound webhooks are built in and cost nothing to try. If you need to receive webhooks or build anything more complex, a visual automation plugin removes the need to write or maintain custom code.

The free version of Krom Automation covers outbound via the HTTP Request action. The Pro incoming webhook receiver handles inbound, with signature verification and per-workflow secret URLs.

The free plugin is available in the WordPress.org plugin directory with no trial period and no run caps. Pro adds the inbound receiver and 24 integrations when you are ready to go further.

See Krom Automation pricing and compare all three plans to find the right fit for your site count and budget.

Frequently Asked Questions

Can I use webhooks in WordPress without knowing how to code?

Yes. WooCommerce includes outbound webhook support in its settings with no code required. For receiving webhooks or connecting non-WooCommerce events, a visual automation plugin like Krom Automation handles the endpoint creation, signature verification and action execution through a drag-and-drop interface.

How do I connect WordPress to Zapier or Make using a webhook?

Create a new Zap or Make scenario with a webhook trigger. Zapier and Make will generate a unique URL.

In WordPress, use an outbound webhook action (via Krom Automation’s HTTP Request action or a WooCommerce webhook) to POST data to that URL when your chosen event fires. To go the other direction and have Zapier push data into WordPress, use the Krom Automation Pro incoming webhook receiver and paste that URL into Zapier’s webhook action.

Why isn’t my WordPress webhook firing?

Work through these checks in order: confirm the trigger event actually fired by checking the execution log, verify the destination URL is publicly reachable and returns a 200 response, confirm the payload format matches what the receiving service expects, and check whether a firewall or hosting rule is blocking outbound HTTP requests on your server.

What is the difference between a webhook and a REST API call in WordPress?

A REST API call is a request your code makes to ask for or send data on demand. A webhook is a notification that fires automatically when an event happens, with no manual trigger required.

The REST API requires something to initiate the call. A webhook initiates itself the moment the event fires.

Is it safe to expose a webhook URL on my WordPress site?

A webhook URL is safe when the receiver validates incoming requests using HMAC signature verification against a shared secret. Without that check, anyone who discovers the URL can send fabricated payloads and trigger your automation. Use a webhook plugin that performs signature verification automatically rather than accepting all incoming requests blindly.