A booking that never reaches the CRM, a record created twice, a reminder sent after payment: these incidents can stem from an automation that was not designed to handle unexpected failures. In 2026, connecting WordPress, a booking platform and business software is only part of the job. For a small business in Nice or Cannes, another question matters: what happens when the connection fails?

A webhook is a notification between applications

A webhook allows a service to notify another application when an event occurs. For example, a payment platform reports a payment to your CRM, which updates the customer record. This notification generally arrives at a web address set up to receive it.

The mechanism seems simple. However, the event, its delivery and the action it triggers are separate things. Receiving a notification does not mean that every step in the workflow has finished.

Acknowledge receipt without losing the work

Depending on the service, a missing response or an error may trigger another delivery. Timing and recovery options vary: no behaviour should be assumed to apply universally.

Ask your provider to separate reception from lengthy operations. For a valid notification that requires processing, the system should first store it durably, then acknowledge receipt according to the supplier's rules. A queue can organise the subsequent work in the background. GitHub specifically recommends asynchronous processing to allow a prompt response.

This acknowledgement does not confirm that the CRM has been updated. If that step fails, your system must retain the task and provide a way to retry it. Responding immediately without securing the stored task could cause the work to disappear after a failure.

Prevent repeated notifications from creating duplicates

Shopify documents the use of a delivery identifier to detect repeated notifications. For your integration, choose the appropriate identifier for the supplier and track its status: received, processing, completed or failed.

Do not mark an action as completed as soon as it arrives. If processing then stops, the next attempt could be ignored even though nothing was completed. Also request protection against concurrent processing of the same event.

The desired behaviour has a technical name: idempotency. Repeating the same operation should produce the same business outcome. An existing booking should therefore update its record rather than create a second one. This protection must also cover external actions, such as sending a message. Where the destination API supports an idempotency key, use it according to its documentation; otherwise, plan to check the outcome before retrying an action whose result is uncertain.

Handle delays and recover missing data

Stripe does not guarantee event delivery order. An older notification should therefore never blindly overwrite a newer state in your CRM. Depending on the API, check the data version or retrieve its current state before making a sensitive change.

Shopify also recommends periodic API checks to reconcile data between systems. Adjust the frequency to your business needs and the service's limits. For example, compare confirmed bookings with the records in your CRM, then review discrepancies before correcting them.

Checks to request before going live

Test an interruption and recovery, rather than only a successful delivery:

  • Resend the same event without creating a new record.
  • Simulate CRM downtime, then verify recovery.
  • Receive an older event after a newer one.
  • Trigger an alert when a task remains stuck.
  • Verify notification authenticity using the supplier's mechanism, including its signature where available.

GitHub's documentation explains, for example, how to verify a signature using a shared secret. Logs should make it possible to find the identifier, timestamp, outcome and any error without unnecessarily copying customer data.

Match reliability requirements to your business

A sole trader in Monaco and a booking business in the Alpes-Maritimes face different constraints. Start with the workflow whose failure would be most costly. NIKAIA.NET can help you design PHP, WordPress and CRM integrations with explicit recovery rules and visible failures.

Points to verify before publication

Review suppliers' current delivery and retry policies, available identifiers, signature mechanisms, support for idempotency keys and API limits. Check that the examples match the connectors actually in use.