Webhooks are one of those integrations that look simple in a demo but can become fragile in real-world environments. A payment gateway may call Odoo to confirm a transaction, or Odoo may send an order update to an external service. Problems can occur when the network is unavailable, the external server times out, or the same payload is received more than once.
Proper error handling and retry strategies help ensure that these failures do not result in lost data or repeated transactions.
Two Directions, Two Different Problems
It helps to separate outbound webhooks from inbound webhooks, as they fail in different ways.
- Outbound webhooks: Odoo sends information to an external service, usually through an automation rule, server action, or custom code.
- Inbound webhooks: An external service sends information to a custom controller exposed by Odoo.
The reason for the outgoing call failing is that the remote server is unresponsive, slow, or prone to errors.Incoming calls may also fail due to Odoo raising exceptions, receiving incorrect data, or duplicated incoming events.
Outbound Webhook Call Failure Handling
One of the pitfalls may be to use requests.post() but not handling timeouts and errors correctly.
In case the remote server takes too long to answer, it will tie up the Odoo worker by sending the request. When the request fails, there will be an exception that the Odoo worker will not be able to handle.
A better approach is to:
- Specify the request timeout.
- Catch the requests.exceptions.RequestException.
- Properly log the failure.
- Track the status of the webhook call.
- Retry the call in case of failure.
For example, the custom webhook.delivery model may have such fields as: destination, payload, status, attempts, next_try.
A scheduled action can then process failed deliveries and retry them using increasing intervals, such as one minute, five minutes, thirty minutes, and then longer intervals. After reaching the maximum retry count, the record can be marked for manual review.
This keeps retry processing outside the normal user request and prevents a slow external service from unnecessarily blocking an Odoo worker.
Handling Inbound Webhook Failures
For inbound webhooks, the priority is to validate the request and respond quickly.
The controller should:
- Validate the webhook signature or authentication.
- Validate the received payload.
- Check whether the event has already been processed.
- Record the event.
- Return the appropriate HTTP response.
- Process the actual business operation separately when required.
Handling Duplicate Webhooks
Webhook vendors will resubmit the event if they do not get a confirmation response within the estimated time frame. Duplicate webhooks have to be managed as part of the integration design.
A unique ID of the event can be recorded as an idempotency key. Odoo can check if the ID is already processed before running the webhook.
This will prevent the same payment or any other transaction from being run twice.
Returning the Correct Response
An HTTP response also determines how the webhook works.
For instance:
- 2xx response > usually means a successful delivery.
- 4xx response > usually means there was a problem with the request.
- 5xx response > implies that there is a problem on the server side and will make the sender resend the message.
Sending back a success message while the process failed will cover up the issue and lead to inconsistencies. The response, thus, needs to show if the webhook was delivered successfully or not.
Setting a Retry Limit
It does not pay to retry indefinitely. The webhook must have a maximum number of tries.
After unsuccessful attempts, take the following steps:
- Cease any more retries.
- Note the reason for failure.
- Flag it for review.
- Inform the concerned person/user.
This will avoid the integration from trying to retry with an endpoint that is not working and allow any persistent failure to be detected more easily.
There are certain factors other than just sending and receiving HTTP requests that must be considered in order for webhooks to be processed effectively. Integrations within Odoo must have timeout, error handling, logging, retries, duplicates detection, and proper retry limitations.
Having webhooks work separately from regular requests and implementing idempotency for incoming events will allow integration to become more reliable.
To read more about A Complete Overview of Webhooks in Odoo 19, refer to our blog A Complete Overview of Webhooks in Odoo 19.