Flow Systems Webhook Actions

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

Trigger HTTP webhooks from any WordPress or WooCommerce action (do_action) and dispatch them asynchronously through a persistent queue with smart retries, event identity, and full delivery visibility.

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.

Typical Use Cases

• 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

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

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.

Flow Systems Webhook Actions allows you to replay any webhook event directly from the delivery logs — including successful deliveries.

This makes it easy to:

• Re-run automation workflows
• Debug external integrations
• Recover from temporary endpoint failures
• Test webhook consumers without recreating WordPress events

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

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
• Store example payloads for configuration
• Modify via fswa_payload filter

Payloads always include stable event metadata for consistency.

Developer Friendly

• Works with any WordPress or WooCommerce action
• Internal REST endpoints power the admin interface
• Fully extensible via filters and actions
• Clean namespace and unique prefixes
• Built according to WordPress.org standards
• Supports system cron for improved reliability

Why Choose Flow Systems Webhook Actions?

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

Flow Systems Webhook Actions provides:

• Persistent queue
• Smart retry logic
• Webhook replay for debugging integrations
• Permanent failure state handling
• Event UUIDs and timestamps
• Full delivery logging and metrics

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
• fswa_headers – Add custom HTTP headers
• fswa_require_https – Toggle HTTPS requirement
• fswa_max_attempts – Configure maximum retry attempts
• 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

Available Actions

• fswa_success – Fired after successful webhook delivery
• fswa_error – Fired after webhook delivery failure