--- title: Webhooks description: "Eventixa Pro includes global Webhooks that can send booking, RSVP, and attendee check-in activity to external applications. Each webhook connects one Eventixa trigger to one HTTP or HTTPS endpoint. Eventixa sends a signed JSON request when the selected lifecycle event…" url: "https://eventixawp.com/docs/webhooks/" updated: "2026-09-27" category: Integration --- # Webhooks Eventixa Pro includes global Webhooks that can send booking, RSVP, and attendee check-in activity to external applications. Each webhook connects one Eventixa trigger to one HTTP or HTTPS endpoint. Eventixa sends a signed JSON request when the selected lifecycle event occurs. > **Available in:** Eventixa Pro > **Admin Location:** Eventixa → Settings → Integrations → Webhooks > **Configuration Scope:** Global > **Delivery Format:** Signed JSON over HTTP POST ## What Are Eventixa Webhooks? A webhook allows Eventixa to notify another application automatically when something happens inside your event system. For example, you could send Eventixa activity to: - CRM systems - Automation platforms - External databases - Custom applications - Notification services - Internal business systems The receiving application must provide an HTTP or HTTPS endpoint that can accept Eventixa's POST request. ## Webhooks Are Managed Globally Eventixa Webhooks are configured globally under **Eventixa → Settings → Integrations → Webhooks**. They are not configured separately inside individual events. A single active webhook definition can receive matching activity from events across the Eventixa installation. ![Eventixa Webhooks settings showing the global Enable Webhooks option and webhook manager](https://eventixawp.com/wp-content/uploads/2026/09/eventixa-webhooks-settings.jpg) Enable Webhooks globally to allow active Eventixa webhook definitions to send booking, RSVP, and check-in activity to external applications. ## Enable Webhooks Globally Open **Eventixa → Settings → Integrations → Webhooks** and enable **Enable Webhooks**. The setting allows Eventixa to send active webhook definitions when their selected trigger occurs. If the global setting is disabled, queued webhook deliveries are not sent. ## Webhook Manager After Webhooks are enabled, Eventixa displays the Webhooks manager. The manager lists existing webhook definitions and provides **Add Webhook** for creating a new one. If no definitions exist, Eventixa displays **No webhooks yet** and prompts you to connect an Eventixa trigger to an external URL. ## Add a Webhook Select **Add Webhook**. The editor includes: - Webhook Name - Status - Trigger - Delivery URL - Secret Key - Description After saving the definition, you can also use **Send Test**. ## Webhook Name Enter a descriptive **Webhook Name** so administrators can recognize its purpose. For example: **Booking Completed CRM** or **Attendee Check-In Automation** The name is only used for administration and does not determine which Eventixa lifecycle event is sent. ## Status Each webhook can be: - Active - Inactive Only active webhook definitions are eligible for normal delivery. An inactive definition remains saved but does not receive matching Eventixa activity. ## Trigger Each webhook definition uses one trigger. The current Eventixa Pro implementation supports these triggers: - Booking Completed - Booking Cancelled - Booking Refunded - RSVP Registered - RSVP Response Updated - RSVP Cancelled - Attendee Checked In ## Booking Completed The **Booking Completed** trigger uses the topic: `booking.completed` It is sent when an eligible Eventixa booking reaches the completed lifecycle event monitored by the webhook integration. ## Booking Cancelled The **Booking Cancelled** trigger uses: `booking.cancelled` This can notify an external system when an Eventixa booking is cancelled. ## Booking Refunded The **Booking Refunded** trigger uses: `booking.refunded` This can be used when another system needs to know that an Eventixa booking has moved into the refunded lifecycle. ## RSVP Registered The **RSVP Registered** trigger uses: `rsvp.registered` It is intended for Eventixa RSVP registration activity. ## RSVP Response Updated The **RSVP Response Updated** trigger uses: `rsvp.updated` Use this when an external application should be notified that an RSVP response has changed. ## RSVP Cancelled The **RSVP Cancelled** trigger uses: `rsvp.cancelled` This notifies the endpoint when an Eventixa RSVP registration is cancelled. ## Attendee Checked In The **Attendee Checked In** trigger uses: `attendee.checked_in` This is useful when another application needs real-time or near-real-time awareness of event entry activity. ## One Trigger per Webhook A webhook definition currently listens to one selected trigger. If the same endpoint should receive several Eventixa topics, create multiple webhook definitions pointing to the same Delivery URL. For example, you can create one definition for Booking Completed and another for Booking Refunded using the same endpoint. ## Delivery URL Enter the destination in **Delivery URL**. The endpoint must use: - `http://` - `https://` A valid hostname is also required. For production integrations, HTTPS is strongly recommended. ## Secret Key Eventixa automatically generates a **Secret Key** when the webhook is created. The secret is used to sign Eventixa webhook requests so the receiving application can verify that the payload came from Eventixa and was not modified in transit. Keep this secret private. ## Show or Hide the Secret The Webhook editor provides a **Show** control for viewing the stored Secret Key when necessary. Avoid exposing it in screenshots, documentation, source repositories, or public support messages. ## Regenerate the Secret When editing an existing webhook, Eventixa can provide **Regenerate the secret when saving**. Enable this option if the current secret has been exposed or you intentionally want to rotate it. Regenerating the secret invalidates the previous signing secret. ## Secret Rotation and Queued Deliveries Eventixa validates the stored signature again before delivering a queued webhook. If the webhook secret changes after a delivery has already been queued, that queued delivery is rejected rather than being sent with a signature that no longer matches the current secret. This prevents stale signed requests from being delivered after a secret rotation. ## Description Use the optional **Description** field for internal notes about the webhook. For example, you can document which application owns the endpoint or what workflow the webhook supports. ## Create Webhook After completing the required fields, select **Create Webhook**. Eventixa generates the webhook ID and signing secret and adds the definition to the Webhooks list. ## Editing a Webhook Select the Edit action beside an existing webhook. You can update its name, status, trigger, Delivery URL, description, and optionally regenerate the signing secret. ## Changing a Trigger Changing a webhook trigger affects future matching Eventixa activity. Eventixa also protects queued deliveries from being sent if the webhook's trigger changed after that delivery was queued. ## Changing the Delivery URL If you change the endpoint after a delivery has already been queued, Eventixa does not send the queued request to the new URL. The queued delivery is rejected because its original endpoint no longer matches the current webhook definition. This helps prevent old payloads from being unexpectedly delivered to a newly configured endpoint. ## Delete a Webhook Use the Delete action to permanently remove a webhook definition. Eventixa asks for confirmation before deletion. Once removed, that webhook no longer receives future matching activity. ## Send Test After the webhook has been saved, select **Send Test** to verify the endpoint. The test request is sent immediately rather than being queued because the administrator needs the HTTP result in the current request. ## Test Payload The test uses the topic: `webhook.test` The payload includes a short Eventixa test message and identifies the webhook definition used for the request. ## Successful Test A webhook test is treated as successful when the endpoint returns an HTTP status in the 200–299 range. Eventixa can display a message such as: **Webhook test delivered successfully (HTTP 200).** ## Failed Test If the endpoint returns a non-success status, Eventixa reports the HTTP result. For example: **Webhook endpoint returned HTTP 404.** Network or request errors are also reported directly to the administrator. ## Webhook Request Method Normal Eventixa webhook deliveries use: **HTTP POST** The request body is JSON. ## Request Content Type Eventixa sends: `Content-Type: application/json; charset=utf-8` and `Accept: application/json` The request also includes an Eventixa-specific User-Agent value. ## Webhook Request Headers Signed webhook requests include these Eventixa headers: - `X-Eventixa-Topic` - `X-Eventixa-Delivery` - `X-Eventixa-Signature` - `X-Eventixa-Version` ## X-Eventixa-Topic `X-Eventixa-Topic` contains the trigger topic. For example: `booking.completed` ## X-Eventixa-Delivery `X-Eventixa-Delivery` contains the unique delivery ID for that payload. The ID can be useful for logging, deduplication, and troubleshooting on the receiving application. ## X-Eventixa-Version `X-Eventixa-Version` identifies the public webhook payload format version. The current webhook payload version is: `1` ## X-Eventixa-Signature `X-Eventixa-Signature` contains the HMAC signature generated from the exact raw JSON body and the webhook Secret Key. The signature format is: `sha256=` ## Signature Algorithm Eventixa uses: **HMAC-SHA256** to sign the exact JSON request body. The receiver should calculate its own HMAC-SHA256 using the shared webhook Secret Key and compare the result with the `X-Eventixa-Signature` header. ## Verify the Exact Raw Body Signature verification should use the exact raw HTTP request body. Do not parse the JSON and then re-encode it before verifying the signature because changes in whitespace or JSON encoding can produce a different HMAC value. ## Example Signature Verification Logic Your receiving application should conceptually: 1. Read the raw request body. 2. Read `X-Eventixa-Signature`. 3. Generate HMAC-SHA256 using the stored Secret Key. 4. Prefix the generated digest with `sha256=`. 5. Compare the values using a timing-safe comparison. 6. Reject the request if the signatures do not match. ## Payload Structure The public Eventixa webhook payload uses a stable envelope containing: - `id` - `topic` - `version` - `created_at` - `event_id` - `data` The exact contents of `data` depend on the webhook topic. ## id The `id` field contains the unique delivery ID. It matches the value sent in `X-Eventixa-Delivery`. ## topic The `topic` field contains the Eventixa trigger topic, such as: `booking.completed` ## version The `version` field identifies the public payload format. The current value is: `1` ## created_at The `created_at` field records when the lifecycle delivery request was created. ## event_id The `event_id` field identifies the Eventixa event associated with the webhook activity. ## data The `data` object contains topic-specific information. The current payload always begins with relevant Eventixa event data and then adds booking, RSVP, or attendee information according to the selected topic. ## Booking Webhook Payloads Topics beginning with `booking.` include both event data and booking data. This applies to: - Booking Completed - Booking Cancelled - Booking Refunded ## RSVP Webhook Payloads Topics beginning with `rsvp.` include event data and an RSVP object containing booking information and RSVP status information. ## Attendee Check-In Payload The `attendee.checked_in` topic includes event data together with attendee information. This lets the receiving system identify both the event and the person who checked in. ## Public Payload Data Webhook payload builders are designed to expose Eventixa's public integration data rather than simply dumping raw WordPress post metadata or internal plugin storage. The exact object fields depend on the booking, event, attendee, and registration data available for the trigger. ## Asynchronous Normal Delivery Normal lifecycle webhooks are delivered through Eventixa's background task system. This means the booking, RSVP, or check-in action does not need to wait for the external webhook endpoint to finish responding. ## Why Delivery Is Queued Using the background task system helps prevent a slow external endpoint from unnecessarily slowing down the Eventixa lifecycle action that triggered the webhook. The Eventixa booking or check-in workflow therefore does not depend on the receiving application being immediately available. ## Delivery Timeout The default webhook HTTP timeout is: **10 seconds** The current implementation constrains the delivery timeout to between 1 and 30 seconds. ## HTTP Redirects Webhook requests allow up to three HTTP redirects. For integrations, it is still better to configure the final endpoint directly rather than relying on redirects. ## Successful Delivery Any HTTP response from 200 through 299 is treated as a successful webhook delivery. ## Retryable HTTP Errors Eventixa treats these delivery failures as retryable: - HTTP 408 - HTTP 429 - HTTP 5xx responses - Network/transport errors - Response status 0 ## Non-Retryable HTTP Errors Other HTTP client errors are not automatically treated as retryable. For example, an endpoint returning HTTP 400 generally indicates that the receiver rejected the request rather than experiencing a temporary service failure. ## Maximum Delivery Attempts Normal webhook delivery tasks use a default maximum of: **3 attempts** This allows Eventixa to retry temporary failures while avoiding unlimited requests to an unavailable endpoint. ## Endpoint Must Still Be Active During Delivery Before a queued request is sent, Eventixa checks the current webhook definition again. Delivery is stopped if the webhook was deleted, disabled, or otherwise no longer has an active endpoint. ## Queued Delivery Integrity Eventixa also confirms that the webhook's current Trigger, Delivery URL, and Secret Key still match the immutable values associated with the queued delivery. If any of these security-sensitive values changed, the stale delivery is rejected. ## Delivery History Is Recorded Internally Eventixa stores webhook delivery history internally. Tracked states can include queued, delivered, retrying, and failed delivery information together with HTTP response details. The current Webhooks manager does not expose a separate delivery-history interface to plugin users. ## Delivery History Retention The internal webhook delivery history uses a default retention period of: **90 days** Older history can be cleaned during Eventixa task cleanup. ## No Per-Event Webhook Configuration The current Eventixa webhook system does not provide per-event webhook definitions. Webhooks are created globally. Use the Eventixa `event_id` and event information inside the payload when your external application needs to handle different events differently. ## Example — Booking Completed Automation Suppose you want completed Eventixa bookings sent to an external CRM. A typical setup is: 1. Enable Webhooks globally. 2. Click **Add Webhook**. 3. Enter a name such as **CRM Booking Completed**. 4. Set Status to Active. 5. Select **Booking Completed**. 6. Enter the CRM webhook URL. 7. Create the webhook. 8. Save the generated Secret Key securely in the CRM. 9. Send a test. 10. Complete a real Eventixa booking. 11. Verify the CRM receives `booking.completed`. ## Example — Check-In Automation To send check-in activity to another system: 1. Add a new webhook. 2. Select **Attendee Checked In**. 3. Enter the receiving endpoint. 4. Create the webhook. 5. Configure signature verification on the external system. 6. Send a test. 7. Check in a test attendee. 8. Verify the external system receives `attendee.checked_in`. ## Example — Multiple Triggers to One Endpoint If the same service needs completed, cancelled, and refunded bookings, create three webhook definitions using the same Delivery URL: - Booking Completed - Booking Cancelled - Booking Refunded Each delivery contains its own `X-Eventixa-Topic` header and payload `topic`. Your receiving endpoint can use the topic to decide what to do. ## Recommended Endpoint Behavior A reliable receiving endpoint should: 1. Accept HTTP POST. 2. Read the raw JSON body. 3. Verify `X-Eventixa-Signature`. 4. Validate `X-Eventixa-Topic`. 5. Track `X-Eventixa-Delivery` to prevent duplicate processing. 6. Process the event safely. 7. Return a 2xx response quickly. 8. Move expensive work into its own background process when possible. ## Idempotency Because temporary delivery failures can be retried, the receiving system should be able to safely handle the same logical delivery more than once. Use the unique `X-Eventixa-Delivery` ID as an idempotency key where possible. ## Respond Quickly Avoid making Eventixa wait for long-running processing inside your endpoint. Validate and accept the request, return a successful 2xx response, and perform expensive work asynchronously on the receiving system when possible. ## Security Recommendations Always use HTTPS for production webhook endpoints. Keep every Eventixa webhook Secret Key private and verify the HMAC signature before trusting the payload. Do not use the webhook name or Delivery URL as proof that a request came from Eventixa. ## Secret Exposure If a webhook Secret Key becomes exposed: 1. Edit the webhook. 2. Enable **Regenerate the secret when saving**. 3. Save the webhook. 4. Update the receiver with the new Secret Key. 5. Re-test the endpoint. Old signatures no longer verify after the secret changes. ## Test Before Going Live Use **Send Test** before relying on a webhook for production automation. A successful test verifies the endpoint and signing workflow, but you should also test the actual lifecycle trigger because test payloads use the separate `webhook.test` topic. ## Recommended Production Test For a Booking Completed webhook: 1. Create the webhook. 2. Send Test. 3. Verify the test signature. 4. Complete a real test booking. 5. Confirm `booking.completed` arrives. 6. Compare the real payload with your receiver's expected fields. 7. Confirm duplicate-delivery handling. 8. Temporarily simulate a retryable error if your test environment allows it. 9. Restore the endpoint to a 2xx response. ## Common Problems ### Webhooks Manager Is Not Visible Confirm Eventixa Pro is active and **Enable Webhooks** is enabled under **Eventixa → Settings → Integrations → Webhooks**. ### Send Test Is Missing Save the webhook first. Eventixa requires an existing webhook definition before it can send a test. ### Test Returns HTTP 404 Verify the Delivery URL and confirm the receiving route exists. ### Test Returns HTTP 401 or 403 The receiving application may require authentication or may be rejecting Eventixa's signature. Check the endpoint's authentication and HMAC verification logic. ### Test Returns HTTP 500 The receiving application encountered a server-side error. Review the external application's logs. ### Real Webhook Does Not Arrive Check that the global webhook setting is enabled, the definition is Active, and the selected Trigger matches the Eventixa lifecycle action that occurred. ### Endpoint Was Changed but an Older Delivery Failed This can be expected because Eventixa refuses to send a queued delivery if its original endpoint no longer matches the current webhook definition. New lifecycle events use the new endpoint. ### Secret Was Regenerated and Queued Deliveries Failed This can be expected because Eventixa refuses stale queued deliveries whose stored signature no longer matches the current Secret Key. ### Webhook Is Inactive Inactive webhook definitions remain saved but do not receive normal lifecycle deliveries. ### Receiving System Processes an Event Twice Normal webhook deliveries can be retried after temporary failures. Use `X-Eventixa-Delivery` as an idempotency key so the receiver can safely ignore duplicate processing. ### Signature Verification Fails Verify that you are calculating HMAC-SHA256 over the exact raw request body and using the correct Secret Key. Do not re-encode the parsed JSON before signature verification. ### I Cannot Find Per-Event Webhooks This is expected. The current Eventixa Webhooks system uses global definitions rather than event-level webhook settings. Use the payload's `event_id` and event data to route activity for specific events in your external application. ### I Cannot Find Delivery History in the UI The current implementation stores delivery history internally but does not expose a dedicated delivery-history screen in the Webhooks settings UI. ## Recommended Configuration For each external workflow: 1. Enable Webhooks globally. 2. Create one webhook per Eventixa trigger you need. 3. Give the webhook a clear administrative name. 4. Use HTTPS for the Delivery URL. 5. Keep the generated Secret Key private. 6. Implement HMAC-SHA256 verification on the receiver. 7. Use `X-Eventixa-Delivery` for idempotency. 8. Send a test. 9. Trigger a real Eventixa lifecycle event. 10. Verify the resulting payload and external workflow. ## Important Notes - Webhooks require Eventixa Pro. - Webhooks are configured globally, not per event. - The current triggers are Booking Completed, Booking Cancelled, Booking Refunded, RSVP Registered, RSVP Response Updated, RSVP Cancelled, and Attendee Checked In. - Each webhook definition listens to one trigger. - Delivery URLs must use HTTP or HTTPS. - Eventixa automatically generates a Secret Key for each webhook. - Requests are signed using HMAC-SHA256. - The signature is sent in `X-Eventixa-Signature`. - Eventixa also sends `X-Eventixa-Topic`, `X-Eventixa-Delivery`, and `X-Eventixa-Version`. - The current public webhook payload version is 1. - Normal webhook deliveries are processed asynchronously. - Successful delivery requires an HTTP 2xx response. - HTTP 408, 429, 5xx, and transport failures are retryable. - Normal delivery tasks use up to three attempts by default. - Changing a webhook's trigger, endpoint, or secret can invalidate already queued deliveries. - Eventixa stores delivery history internally for up to 90 days by default, but there is currently no dedicated delivery-history screen in the admin UI. - Send Test uses the separate `webhook.test` topic and is delivered immediately. ## Related Documentation - [Integrations Overview](https://eventixawp.com/docs/integrations-overview/) - [Managing Bookings](https://eventixawp.com/docs/managing-bookings/) - [Booking Statuses](https://eventixawp.com/docs/booking-statuses/) - [RSVP Tickets](https://eventixawp.com/docs/rsvp-tickets/) - [Managing Attendees](https://eventixawp.com/docs/managing-attendees/) - [Event Check-In](https://eventixawp.com/docs/event-check-in/) - [MailPoet Integration](https://eventixawp.com/docs/mailpoet-integration/) - [Mailchimp Integration](https://eventixawp.com/docs/mailchimp-integration/) - [WooCommerce Integration](https://eventixawp.com/docs/woocommerce-integration/)