Free tools Windows power users keep installed
One-click scans. No signup required.
A retry answers one question: “Can I send this again?” Recovery answers a different one: “What state are Odoo and the other system actually in, and what has to change to make them agree?” Treating the first as the second is how integrations create duplicate invoices, orphaned records and silent gaps.
This article gives a working model for deciding, per failure, whether to retry, correct or reconcile before replay. It is an operating model assembled from documented Odoo behavior. Odoo does not prescribe a retry standard, and its documentation does not promise that repeating a business operation is safe.
As an Amazon Associate I earn from qualifying purchases.
The short version: three outcomes, not two
| Situation | Action | Typical signals |
|---|---|---|
| Transient and repeating is safe or protected | Retry, with limits | Connection failure before the request could have been processed; operation is read-only or protected against duplicates |
| Request was understood and rejected | Correct, then resubmit | Authentication or permission denial, invalid data, field-mapping or configuration error |
| Outcome unknown or partially applied | Reconcile first, then decide | Timeout, connection reset or client cancellation after a write-type call was sent |
The reviewed Odoo sources do not establish that all 5xx errors are transient or that all 4xx errors are permanent. Status codes are evidence, not verdicts.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Step 1: Capture the operation context
You cannot reconcile what you did not record. For every integration job, keep:
#1 Best Overall
- A job or integration identifier and the request timestamp.
- Odoo version and hosting arrangement (for example Odoo Online versus another deployment), since access and endpoint availability differ.
- The endpoint, model and method, or the webhook rule involved.
- A sanitized payload identity: a hash or the business keys, not the raw body if it holds secrets.
- The remote event or business record identifier from the external system.
Never log API keys. Never log a webhook URL either: Odoo’s webhook documentation states, “The URL is confidential and should be treated with care.” (Odoo 19.0, Webhooks)
Step 2: Classify what you actually know
Separate a confirmed response from the absence of one.
A response arrived: read both layers
In Odoo 19’s External JSON-2 API, requests are POSTs to /json/2/<model>/<method> with a bearer API key and a JSON body. Odoo documents success as “a 200 status with the JSON-serialized return value of the called method in the body,” and failure as “a 4xx/5xx status with a JSON-serialized error object in the body.” The error object can carry the exception name, message, arguments, context and debug details, so log it rather than just the status code. (Odoo 19.0, External JSON-2 API)
Do not carry that rule over to every Odoo interface. Odoo’s web-client RPC service, documented for 18.0, can deliver server errors with HTTP 200 and an error key in the response, and it handles network errors separately, retrying contact until a response arrives. That is frontend behavior and does not define a backend retry policy. (Odoo 18.0, Services) If your code touches both kinds of endpoint, check the body as well as the status for the web-client style.
No response arrived: the outcome is unknown
Timeouts, connection resets, DNS or TLS failures and client-side cancellations tell you the caller did not see an answer. They do not tell you whether Odoo processed the request. A DNS failure almost certainly means nothing was sent; a timeout after the body was transmitted means anything could have happened. Record which one occurred.
Step 3: Check whether the intended state changed
Before resubmitting any non-idempotent action (creating a record, posting, confirming, sending), look. Query Odoo for the record using a stable business identifier, such as an external reference your system wrote into a field, or inspect the downstream state. Then:
- State changed as intended: mark the job complete; do not replay.
- State unchanged: replay is reasonable if the original failure cause is gone.
- State partly changed: treat as reconciliation work, completing or reversing the missing part deliberately.
- Cannot tell: hold the job for review rather than guess.
This is engineering guidance, not a documented Odoo guarantee. It only works if you designed for it: put your own idempotency key or external ID on the records you create, so that “did it already happen?” has a cheap answer.
Step 4: Choose the recovery action
Retry
Retry when the failure looks transient and repeating is safe or protected: reads, operations keyed by an external identifier you can check, or a failure that provably occurred before the request left your system. Use bounded attempts with backoff and a durable record of each attempt.
Correct
Fix the cause, then resubmit. Examples:
- Authentication or permission denial. JSON-2 requires bearer API-key authentication and applies standard access rights, record rules and field access. Odoo recommends dedicated bot users for extended automated use, with the least permissions required. A denial means investigating the key, its expiry, the user’s groups and record rules, not looping. (Odoo 19.0, External JSON-2 API)
- Webhook configuration or mapping. Odoo’s 18.0 testing guidance says a
200 OKorstatus: okmeans the webhook is working on Odoo’s side, and other statuses help locate problems, with a 500 given as an example of field-mapping or configuration trouble. (Odoo 18.0, Webhooks) Resending the same payload to a misconfigured rule only repeats the failure. - Invalid data. Read the error message and arguments, fix the source record, then resubmit.
Reconcile
For unknown or partial outcomes, compare the two systems, repair the difference, then resume from a durable checkpoint, such as the last confirmed remote event ID, rather than from “now.”
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Webhooks: what a success actually proves
Webhooks and API calls differ on the axes that matter for recovery.
| Axis | External JSON-2 API | Studio webhook |
|---|---|---|
| Direction | Your system calls Odoo model methods | An external sender POSTs an event into an Odoo database |
| Response visibility | Caller sees status and a JSON body or error object | Sender sees the HTTP result; Odoo-side success does not prove the sender is correct |
| Configuration | API key, user permissions, model and method | Webhook rule, payload field mapping, confidential URL |
| Diagnostics | Structured error object | Optional call logging with request history |
| Access constraints | Odoo’s docs state external API access is only on Custom plans, not One App Free or Standard | Version and Studio availability should be confirmed for your deployment |
A 200 OK from a test call is an Odoo-side signal only. The sender still has to be implemented and verified. Odoo’s guide describes enabling call logging for troubleshooting, which preserves request history you can use to see what arrived when the sender and Odoo disagree. If the URL leaks, rotate the secret and update the external sender afterward, or deliveries will begin to fail. (Odoo 19.0, Webhooks)
Odoo also recommends configuring and testing webhooks on a duplicate database before using them live, and advises involving a developer or solution architect, since a wrong setup can disrupt the database and take time to undo. For complex failure diagnosis, an Odoo integration developer is the right person to bring in.
Step 5: Instrument and test
- Enable webhook call logging where you need history, and treat the logs as sensitive.
- Test with representative payloads, including malformed ones and ones that duplicate an earlier event.
- Rehearse the ambiguous case deliberately: kill the connection after sending a write and confirm your reconciliation step detects that it was applied.
- Run all of this on a duplicate database first.
Step 6: Plan for the API migration
The failure model depends on which endpoint you call. Odoo 19 documentation says the external XML-RPC and JSON-RPC endpoints (/xmlrpc, /xmlrpc/2, /jsonrpc) are scheduled for removal in Odoo 22 (fall 2028) and Odoo Online 21.1 (winter 2027), with External JSON-2 as the replacement. The notice does not apply to other controllers declared with @route(type='jsonrpc'). (Odoo 19.0, External RPC API) Dates are version-specific, so recheck them against your deployment.
When you migrate, don’t port error handling line by line. Legacy RPC and JSON-2 report errors differently, so rewrite the classification step: status code plus error object for JSON-2.
A worked example
Your shop system pushes an order to Odoo through JSON-2 and the call times out.
Windows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallOutdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware match- Classify: no response, so the outcome is unknown. Record the order’s external ID.
- Check: search Odoo for a sales order carrying that external ID.
- Found: mark the job done. Not found: retry once the connectivity problem clears, using the same external ID.
- If the retry returns 403, stop retrying. Check the key’s expiry and the bot user’s access rights, then resume.
The same event could come back as a 4xx with a validation message. That goes to correction, not replay.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
