Core Concepts
Zapify Webhooks: Receive and Send Webhooks in WordPress
Webhooks let Zapify talk to services that WordPress has no built-in trigger for. Zapify both receives webhooks — turning an incoming request from Stripe, GitHub, Zapier, or your own script into an automation trigger — and sends them, posting to any URL as an action. Incoming webhooks (up to three sources) and outgoing webhooks are free; advanced controls such as auth, retries, and replay are PRO.
Receiving webhooks
Add the A webhook is received trigger to an automation. Zapify generates a public endpoint with a long random key in the URL:
POST|GET https://your-site.com/wp-json/zapify/v1/hook/{key}
The key is the credential — 16 to 64 alphanumeric characters — so treat the URL as a secret. Anything that can POST JSON can drive an automation this way: Stripe, Paddle, GitHub, Zapier, or a script of your own.
The endpoint is rate-limited to protect your site: 60 requests per key per minute and 300 requests per address per minute across all keys. The largest body accepted is 512 KB.
Listen mode
Rather than guessing what a service sends, use Listen. Zapify captures the next delivery and builds the token list from the payload it actually received, so you pick from real field names instead of reading someone's API documentation.
Webhook sources
A source is one URL that feeds many automations, each selecting itself on the payload — usually the event type. One Stripe endpoint can drive a dozen automations without configuring a dozen URLs at Stripe's end.
The free build supports up to three sources. Removing that limit is PRO.
PRO feature
Unlimited webhook sources (webhook_sources) is a Zapify PRO feature. The free build supports up to three incoming sources; PRO removes the cap.
Signature verification
Signature verification, rate limiting, and a per-source key all come with incoming webhooks on the free plan. Verified signatures are supported for the common providers. Stripe and Paddle sign a timestamp joined to the body rather than the body alone, and Zapify handles them as such — deliveries outside a five-minute window are refused even when the signature verifies, so a captured delivery cannot be replayed indefinitely.
Deduplication
Providers retry deliveries. Zapify records a deduplication key per delivery with a unique index, so the same delivery arriving twice runs the automation once, even if both copies arrive at the same instant.
PRO additions for incoming webhooks
PRO feature
Zapify PRO adds several controls on top of the free incoming-webhook path:
- Webhook auth & signing (
webhook_auth) — reusable auth profiles and secret rotation for zero-downtime key changes. - Retry policies (
webhook_retries) — control how failed deliveries are retried. - Advanced subject resolution (
webhook_subject) — resolve which record a payload refers to using richer rules.
Sending webhooks
The Send a webhook action posts to any URL and is available on the free plan. You set the method, headers, and a body built from fields or written raw. Authentication can be a reusable connection or set per action.
What Send a webhook will not do
Requests to loopback, link-local, and private network ranges are refused unless you explicitly allow them by defining ZAPIFY_ALLOW_INTERNAL_REQUESTS. The hostname is resolved and re-checked after redirects, so a public URL that redirects to 127.0.0.1 does not get through either.
That is deliberate: without this guard, any admin who can build an automation could make your server fetch anything on your internal network (an SSRF risk).
Dry-run and bulk replay
PRO feature
Dry-run and bulk replay (webhook_replay) is a Zapify PRO feature.
Every incoming delivery is kept. In PRO, Dry run explains why a delivery did not match a particular automation, and bulk replay re-runs a filtered set of deliveries — useful after fixing an automation that was misconfigured while deliveries were arriving.
Conclusion
Zapify's free plan covers the essentials: receive webhooks from up to three sources with signature verification, rate limiting, and deduplication, and send webhooks with an SSRF guard. PRO removes the source limit and adds auth and signing, retry policies, advanced subject resolution, and dry-run/bulk replay. For a hands-on walkthrough, see Send an email when a webhook is received, and compare plans in Zapify Free vs Pro.
FAQs
Are Zapify webhooks free?
Yes, in part. Receiving webhooks from up to three sources — with signature verification, rate limiting, per-source keys, and deduplication — is free, as is the Send a webhook action with its SSRF guard. Unlimited sources, webhook auth and signing, retry policies, advanced subject resolution, and dry-run/bulk replay are Zapify PRO features.
How many incoming webhook sources can I have on the free plan?
The free build supports up to three incoming webhook sources. A source is one URL that can feed many automations, each selecting itself on the payload, so three sources is more capable than three automations — one source can drive a dozen automations. Removing the three-source limit requires Zapify PRO (webhook_sources).
What is the webhook endpoint URL and is it secure?
Zapify generates an endpoint at /wp-json/zapify/v1/hook/{key}, where the key is 16 to 64 alphanumeric characters. The key in the URL is the credential, so keep it secret. The endpoint is rate-limited to 60 requests per key per minute and 300 per address per minute, accepts bodies up to 512 KB, and supports signature verification for common providers.
Can Zapify webhooks reach my internal network?
No, not by default. The Send a webhook action refuses requests to loopback, link-local, and private network ranges, and re-checks the hostname after any redirect, so a public URL that redirects to 127.0.0.1 is still blocked. This prevents SSRF attacks. You can override it by defining the ZAPIFY_ALLOW_INTERNAL_REQUESTS constant if you genuinely need internal requests.
Does Zapify run duplicate webhook deliveries twice?
No. Providers routinely retry deliveries, so Zapify records a deduplication key per delivery with a unique database index. If the same delivery arrives twice — even simultaneously — the automation runs only once. This protects against double-processing when a provider re-sends a webhook it was not sure you received.