Webhook Actions by Flow Systems is a developer-focused WordPress webhook delivery layer designed for reliable automation workflows.

It adds a persistent queue, automatic retries, and Action Scheduler support for production-grade background processing — so your webhooks don’t get lost when external APIs fail.

Works great with WooCommerce, n8n, Zapier alternatives, and custom APIs.

Any WordPress do_action hook can become a reliable event source — register it as a trigger and the plugin handles queuing, retries, payload mapping, and delivery from there. No custom delivery code required.

Includes built-in Contact Form 7 integration — send CF7 form submissions to webhooks instantly with clean, structured payloads. Replace fragile CF7 email workflows with reliable webhook-based automation.

Unlike basic “fire-and-forget” webhook implementations, this plugin ensures:

Delivery attempts are tracked
Failures are visible
Retries are automatic and intelligent
Events include stable identity metadata for idempotency

Built for production environments where losing events is not acceptable.

👉 Step-by-step example: Send Contact Form 7 submissions to a webhook (n8n demo)
👉 Step-by-step example: Send Gravity Forms Submissions to n8n
👉 Step-by-step example: Send IvyForms submissions to a webhook (n8n demo)

⚡ Webhook Actions Pro

Unlock unlimited conditions, per-webhook retry and backoff settings, type casting in payload mapping, and more.

See pricing and upgrade

Typical Use Cases

CF7 to Webhook: Send Contact Form 7 Data to n8n or external APIs
Gravity Forms webhooks for sending submission to CRM
Send IvyForms submissions to n8n or external APIs
Build reliable form-to-CRM integrations with retry protection
Process high-volume WooCommerce webhooks using Action Scheduler
Send WooCommerce orders to n8n with retry protection
Sync WordPress users to external CRMs safely
Trigger backend microservices from WP hooks
Send event-driven data to internal APIs
Replace fragile custom wp_remote_post() integrations
Build idempotent WordPress automation pipelines
Query delivery logs, trigger retries, or manage webhooks programmatically from CI/CD pipelines or external dashboards using API tokens
Allow AI coding assistants (e.g. Claude Code) to inspect webhook logs and retry failed events automatically
Use AI agents to monitor webhook delivery health and operate the queue through the REST API

Event Identity & Idempotency

Every dispatched webhook includes:

Unique UUID (v4) per event
ISO 8601 UTC timestamp
Embedded event.id, event.timestamp, event.version in the payload
HTTP headers: X-Event-Id, X-Event-Timestamp, X-Webhook-Id

X-Webhook-Id carries the webhook’s own stable UUID — distinct from the per-event X-Event-Id. When multiple webhooks point to the same endpoint, the receiving system can use X-Webhook-Id to identify which webhook configuration triggered the delivery without inspecting the payload.

This enables downstream deduplication, idempotent workflow design, and reliable debugging across systems.

Reliable Queue & Smart Retry

Webhooks are never sent directly from request execution. Instead:

Events are stored in a persistent database queue
Processed asynchronously via background jobs
Dispatched in batches to avoid performance impact

Smart retry routing:

5xx and 429 responses automatic exponential backoff retry
4xx and 3xx responses immediately marked as permanently_failed
Configurable maximum retry attempts
Full attempt history stored per event

No silent failures.

Replay Webhook Events

Webhook debugging is difficult when events cannot be reproduced.

Webhook Actions by Flow Systems allows you to replay any webhook event directly from the delivery logs — including successful deliveries and condition-skipped events.

This makes it easy to:

Re-run automation workflows
Debug external integrations
Recover from temporary endpoint failures
Test webhook consumers without recreating WordPress events
Re-evaluate previously skipped events after changing webhook conditions

Each replay uses the original payload and event metadata, ensuring consistent behavior across retries and debugging sessions.

Conditional Dispatch

Not every WordPress event should trigger a webhook. Conditional dispatch lets you define field-level rules on any webhook — the event is only delivered if the conditions pass. Events that fail the check are logged with a skipped status and can be replayed later after adjusting the conditions.

Conditions are evaluated against the outgoing payload using dot-notation field paths. Each condition specifies a field, an optional type cast, an operator, and a comparison value. The field selector shows the live captured payload so you can click through nested structures and pick the exact path without typing it manually.

Operators include: equals, not equals, contains, starts with, ends with, is empty, has value, greater than, less than, array_contains, object_contains

Type casting before comparison: auto-detect, number, string, boolean, or stringify (JSON-encodes arrays and objects into a string for pattern matching)

Example — WooCommerce: fire only when a specific product is in the order

A woocommerce_order_status_changed hook passes the full order object. The payload includes args.1.line_items — an array of purchased products, each with fields like product_id, quantity, and subtotal. To send a webhook only when product ID 26 appears in the order:

Field: args.1.line_items
Operator: has value key: product_id, value: 26

The webhook stays silent for every other order and fires only when that product is purchased. No custom PHP, no extra filters — just a condition rule configured in the admin panel.

The same pattern works for any hook-based event: filter by post type, form field value, user role, order total, or any other field present in the payload.

Free plan includes one condition with AND matching. Upgrade to Pro for unlimited conditions, multiple condition groups with independent AND/OR logic per group, and ANY (OR) matching.

Synchronous Execution

By default, all webhooks are delivered asynchronously via the built-in queue — events are stored, processed in the background, and retried automatically on failure. This is the recommended approach for production sites.

For specific webhooks that require inline delivery (e.g. an internal API that must respond within the same request), you can enable Synchronous Execution per webhook:

The webhook fires during the WordPress request that triggered it — no queue delay
The first attempt runs blocking in the current request
If that attempt fails with a retryable error (5xx, transport error), it automatically falls back to the queue with standard exponential backoff starting at attempt 2
Non-retryable failures (4xx) are marked permanently failed immediately
A warning dialog must be acknowledged before enabling, and can be dismissed permanently per-browser

Use with caution on user-facing requests — a slow or unreachable endpoint will delay page loads, form submissions, and other frontend interactions.

Delivery Observability

Operational visibility built into the admin panel:

Status states: pending, processing, success, failed (retrying), permanently_failed

Attempt timeline per event
HTTP status codes and response bodies
Inspect full request payloads
Manual retry (single or bulk)
Replay webhook events for debugging and testing integrations

Filter by: event UUID, target URL, date range, status

Queue health metrics:

Average attempts per event
Oldest pending job age
Queue stuck detection
WP-Cron-only warning

Designed as an operations console — not just a webhook sender.

Payload Mapping

Adapt outgoing JSON payloads to match any external API:

Rename fields using dot notation
Restructure nested objects
Exclude sensitive or unnecessary data
Cast field values to number, string, or boolean before sending (e.g. WooCommerce price "100.50" 100.5)
Store example payloads for configuration
Modify via fswa_payload filter

Payloads always include stable event metadata for consistency.

Configurable HTTP Requests

Every webhook can be configured to match exactly what the target API expects:

HTTP Method

Choose the method used for each delivery: GET, POST, PUT, PATCH, or DELETE. Default is POST.

Custom Request Headers

Add any number of key/value header pairs sent with every delivery. Header values support dot-notation paths — reference any field from the outgoing payload directly (e.g. event.id, site.url). Resolved at dispatch time against the live payload.

URL Query Parameters

Append query parameters to the endpoint URL at dispatch time. Values also support dot-notation payload resolution.

For GET and DELETE requests — where a request body is not appropriate — query parameters become the primary payload transport. If no params are configured, the full payload is sent as a ?payload= fallback. POST, PUT, and PATCH send a JSON body as normal; any configured params are appended to the URL in addition.

Request details in delivery logs

Every delivery log stores the exact headers sent and the fully resolved URL (including all query parameters), so you can inspect precisely what was dispatched.

REST API Access with Token Authentication

The plugin exposes a full operational REST API (/wp-json/fswa/v1/) that powers the admin interface and can also be used directly by external tools, automation systems, AI agents, and CI/CD pipelines.

Every endpoint supports dual authentication:

WordPress admin session (cookie-based, used by the admin panel)
API token — for programmatic access without a browser session

API Tokens

Create tokens directly from the API Tokens screen in the admin panel. Each token is assigned one of three scopes:

read — GET access to webhooks, logs, queue, health, triggers, and schemas
operational — Read + toggle webhooks on/off, retry and replay log entries, execute queue jobs
full — Operational + create, update, and delete webhooks, schemas, and queue jobs

Token authentication is accepted via:

X-FSWA-Token: <token> header (recommended)
Authorization: Bearer <token> header
?api_token=<token> query parameter

Tokens can be set to expire and rotated at any time. Rotation issues a new secret immediately while preserving the token’s name, scope, and settings. Token management always requires a WordPress admin login — tokens cannot be used to create or manage other tokens.

Full REST API documentation: REST API Reference

AI Agents and Programmatic Automation

The REST API makes Webhook Actions by Flow Systems accessible to AI-powered tools and coding agents.

Automation systems, CI pipelines, and AI coding assistants (such as Claude Code or Cursor) can safely interact with webhook infrastructure using API tokens without requiring WordPress admin sessions.

Typical AI-driven workflows include:

AI agents monitoring webhook delivery health
Automatically retrying failed webhook events
Inspecting delivery logs to debug integrations
Enabling or disabling webhooks dynamically during deployments
Managing automation pipelines across environments

Because the API exposes operational endpoints for logs, queue jobs, webhooks, and triggers, external agents can treat WordPress as a programmable event infrastructure.

Example scenarios:

• A Claude Code agent analyzes webhook delivery logs and automatically retries failed integrations.
• A CI/CD pipeline disables webhook triggers during deployments and re-enables them afterward.
• Automation systems query webhook health metrics and alert when the queue becomes stuck.
• External dashboards display real-time webhook delivery metrics using API tokens.

This allows WordPress automation pipelines to be controlled entirely through HTTP APIs, enabling advanced integration with AI-driven development workflows.

Webhook Actions Pro (full feature list)

Webhook Actions Pro extends the plugin with advanced features for production workflows:

Unlimited conditions and condition groups with AND/OR logic
Type casting in conditions — cast field values to number, string, or boolean before comparison
Type casting in payload mapping — cast values before sending to external APIs
Per-webhook retry settings — override maximum retry attempts at the webhook level
Per-webhook backoff strategy — override retry delay behavior per webhook
License managed directly from the Pro tab in the admin panel

Learn more and upgrade

Contact Form 7 Webhooks

Webhook Actions by Flow Systems includes built-in integration with Contact Form 7.

When Contact Form 7 is active, form submissions are automatically converted into structured webhook payloads — no custom code required.

Included in each payload:

Form ID and title
Submission data (all fields)
Normalized field structure (no raw CF7 format)
Request metadata
Uploaded files (where applicable)

Benefits:

Send CF7 submissions to n8n, APIs, CRMs, or automation tools
No need for custom hooks or additional plugins
Clean JSON payloads ready for external processing
Works with existing webhook retry, queue, and replay system

This allows you to build reliable form-to-automation pipelines directly from WordPress.

Action Scheduler Support

Webhook Actions by Flow Systems now supports Action Scheduler — the same background job system used by WooCommerce.

When available, webhook queue processing automatically switches from WP-Cron to Action Scheduler for improved reliability and scalability.

Benefits:

More reliable background execution than WP-Cron
Better handling of high-volume webhook traffic
Persistent job tracking and recovery
No configuration required — automatic detection and migration

This makes the plugin suitable for production WooCommerce stores and high-throughput automation pipelines.

Developer Friendly

Works with any WordPress or WooCommerce action
Full REST API (/wp-json/fswa/v1/) usable from any HTTP client — not just the admin panel
API token authentication with scoped access (read, operational, full)
Configurable HTTP method, custom headers, and URL query parameters per webhook
Fully extensible via filters and actions
Clean namespace and unique prefixes
Built according to WordPress.org standards
Supports system cron, WP-Cron, and Action Scheduler (auto-detected)

Why Choose Webhook Actions by Flow Systems?

Most WordPress webhook setups fire once, don’t retry intelligently, don’t provide delivery visibility, and don’t expose event identity.

Webhook Actions by Flow Systems provides:

Persistent queue
Smart retry logic
Webhook replay for debugging integrations
Permanent failure state handling
Event UUIDs and timestamps
Full delivery logging and metrics
Configurable HTTP method, custom headers, and URL query parameters per webhook
Conditional webhook dispatch
Per-webhook synchronous execution — optional inline delivery with automatic queue fallback on failure
Test webhook delivery — send a test event instantly or via queue without triggering real WordPress events
REST API with token authentication for programmatic access
Action Scheduler support for reliable background processing (when available)
Built-in CF7 to webhook support (no extra plugins needed)

Upgrade to Webhook Actions Pro for unlimited conditions, per-webhook retry and backoff settings, and more.

Built for developers who need production-grade automation reliability.

Available Filters

fswa_should_dispatch – Decide if a trigger should dispatch
fswa_payload – Customize webhook payload before dispatch
fswa_capture_payload – Modify the payload just before it is stored as the captured example (does not affect the dispatched payload); args: $payload, $webhookId, $trigger
fswa_normalize_object – Normalize a third-party object into an array for payload serialization
fswa_headers – Add or modify HTTP headers sent with the request
fswa_require_https – Toggle HTTPS requirement
fswa_max_attempts – Configure maximum retry attempts
fswa_backoff_delay – Customize retry backoff delay in seconds
fswa_queue_batch_size – Configure batch processing size
fswa_http_timeout – Configure HTTP request timeout
fswa_http_connect_timeout – Configure HTTP connect timeout
fswa_http_args – Customize HTTP request arguments
fswa_available_triggers – Customize available trigger list
fswa_webhook_data – Filter webhook configuration data returned by the REST API

Available Actions

fswa_success – Fired after successful webhook delivery
fswa_error – Fired after webhook delivery failure
fswa_skipped – Fired when a webhook dispatch is skipped due to a …