
Summarize with AI
Is XML-RPC removed in Odoo 20? The updated JSON-2 API timeline
Key takeaways:
- XML-RPC is not fully removed in Odoo 20. Only the db service is gone. The common and object services still work but are deprecated.
- Odoo plans to remove common and object in Odoo 22 (fall 2028) and Odoo Online 21.1 (winter 2027).
- The Odoo 20 JSON-2 API is the replacement. It uses API keys, one URL per model method, and one database transaction per call.
- The external API only works on Odoo’s custom pricing plan, so some Odoo Online users have no API access at all.
- Start with database scripts, order and stock syncs, and any vendor connector that cannot show a JSON-2 plan in writing.
Most Odoo integrations were built once and then forgotten. An order sync written five years ago still runs every few minutes, and the person who wrote it may have left the company. Nobody checks which API it uses until an upgrade breaks it.
That is why the Odoo 20 XML-RPC API timeline matters. The short answer is that XML-RPC is not removed in Odoo 20. One part of it is, and the rest has a fixed end date. Teams that read “still works” as “safe” are the ones who will be rewriting connectors under pressure in 2028.
Key numbers at a glance
- 87% of organizations had an API security incident in the past year, up from 76% in 2022, according to Akamai’s 2026 API Security Impact Study. Old integrations with broad access are part of that risk.
- The same study puts the average cost of one API incident above $700,000. A forgotten connector running on an admin login is an expensive way to find this out.
- Daily API attacks per organization rose 113% year over year, according to Akamai’s 2026 State of the Internet report. A migration is the right moment to close old doors, not just open new ones.
The Odoo 20 XML-RPC API timeline, step by step
Odoo XML-RPC deprecation happens in stages, not all at once. Each stage hits a different kind of integration.
| Release | Odoo Online | What changes | Who is affected |
|---|---|---|---|
| Odoo 19 (2025) | Online 19.0 | XML-RPC and /jsonrpc marked deprecated. JSON-2 introduced. | Nobody breaks yet. Planning should start. |
| Odoo 20 (fall 2026) | Online 19.1 (winter 2025) | db service removed | Scripts that list, create, copy, back up or restore databases |
| Odoo 21 (2027) | Online 21.1 (winter 2027) | common and object removed on Online | Every Online integration still using XML-RPC |
| Odoo 22 (fall 2028) | Already removed | common and object removed on-premise and Odoo.sh | Every remaining XML-RPC or /jsonrpc integration |
Two things in this table are easy to miss.
First, Odoo Online runs about a year ahead of the numbered releases, so an online customer has less time than the version numbers suggest. Second, “deprecated” in Odoo 19 already meant no new work should be built on XML-RPC. Anything built since then is new debt.
Odoo also notes that these dates can shift.
Check the official documentation before you lock an Odoo API migration timeline into a project plan.
Odoo XML-RPC vs JSON-2: what actually changes
Most of the Odoo 20 API changes have little to do with XML versus JSON. The bigger shift is in how an integration logs in, how it calls methods, and how it handles failures.
| - | XML-RPC (legacy) | JSON-2 (new) |
|---|---|---|
| Endpoint | /xmlrpc/2/common and /xmlrpc/2/object | /json/2/<model>/<method> |
| Login | Username and password or key, then a uid | API key sent as a bearer token on every request |
| Calling a method | execute_kw with positional arguments | HTTP POST with named arguments in a JSON body |
| Database choice | Passed inside each call | X-Odoo-Database header, needed when one server hosts several databases |
| Transactions | One per call | One per call, and calls cannot be chained into one transaction |
| Status | Deprecated | Recommended for all new work |
The transaction rule deserves attention. Each JSON-2 call is committed on its own. An integration that creates an order in one call and its lines in the next can leave a half-built order behind if the second call fails. Good JSON-2 integrations either do the whole job in one method call or are built so that a retry does not create duplicates.
API keys also behave differently now. Odoo asks for a duration when a key is created, so keys expire. A connector that worked for years can stop on a Monday morning simply because its key ran out. Put key expiry dates in the same calendar as your SSL certificates.
What a JSON-2 call looks like next to execute_kw
The easiest way to see the change is to put the same request side by side. Both examples below read the names of companies from the contact list.
The legacy XML-RPC version logs in first, then calls execute_kw:
import xmlrpc.client
common = xmlrpc.client.ServerProxy(f"{url}/xmlrpc/2/common")
uid = common.authenticate(db, username, api_key, {})
models = xmlrpc.client.ServerProxy(f"{url}/xmlrpc/2/object")
partners = models.execute_kw(
db, uid, api_key,
"res.partner", "search_read",
[[["is_company", "=", True]]],
{"fields": ["name"], "limit": 5},
)The JSON-2 version skips the login step and calls the model method directly:
import requests
response = requests.post(
f"{url}/json/2/res.partner/search_read",
headers={
"Authorization": f"bearer {api_key}",
"X-Odoo-Database": db,
},
json={
"domain": [["is_company", "=", True]],
"fields": ["name"],
"limit": 5,
},
)
partners = response.json()The JSON-2 call is shorter, uses plain HTTP, and needs no XML library. Arguments are named so a reader can tell what each value means.
Odoo’s JSON-2 API documentation also describes a live reference page at /doc on each database, which lists the models and methods that the instance exposes. It is the fastest way to map old calls to new ones.
What a failed JSON-2 call looks like
When a call fails, JSON-2 returns an HTTP error status with a JSON body that describes the problem. A missing or invalid API key returns 401 Unauthorized. Permission problems, missing records, and validation errors come back as Odoo error messages in the response body.
Three habits prevent most surprises:
- Check the status first: Read the result only after confirming the call succeeded.
- Log the error message: Store the message Odoo returns, so support teams can see what went wrong.
- Retry with care: Retry timeouts and network errors. Do not retry calls that failed because of bad data, or the same error will repeat.
Check your plan before you plan the migration
Many migration guides skip a basic question: can your Odoo instance use the external API at all? According to Odoo’s documentation, any Odoo external API integration needs a custom pricing plan. External API access is not available on One App Free or Standard plans.
This catches some Odoo Online customers off guard. A business on the Standard plan that relies on a third-party connector should confirm how that connector reaches Odoo, because a direct XML-RPC or JSON-2 connection will not work on that plan.
PHP integrations have a second, quieter problem. Odoo’s documentation notes that from PHP 8 onward, the XML-RPC extension may not be installed by default. Many WooCommerce and custom PHP connectors use it. A server upgrade can break them before Odoo ever removes anything.
Which integrations should migrate first
Prioritize by two things, that is, how soon the call breaks and how much damage a failure causes. A broken monthly report is an annoyance. A broken order sync is lost revenue by lunchtime.
A practical order:
- Database admin scripts: Anything calling the db service is already broken on Odoo 20 and Online 19.1. Move backup, restore, and duplication jobs to your hosting tools or the Odoo.sh interface.
- Order and stock syncs: Ecommerce, marketplace, and warehouse connections run all day. A failure here means overselling and late shipments.
- Accounting connectors: Payment, invoice, and bank feeds. Failures here are quiet, and finance often finds them at month-end.
- Customer-facing apps and portals: Customers notice outages before your team does.
- Vendor connectors without a JSON-2 plan: If the vendor cannot show you a written roadmap, start looking at alternatives now.
Internal reports and one-off scripts can wait, but they should still go on the list.
Questions to ask your connector vendors
A vendor saying their app “supports Odoo 20” does not tell you which API it uses. Ask these questions and get the answers in writing:
- Which Odoo endpoint does your connector call today: /xmlrpc, /jsonrpc, or /json/2?
- Do you have written Odoo 20 API compatibility, and which later versions are covered?
- When will your JSON-2 version ship, and will it need new API keys or settings?
- Does any feature depend on the db service, such as backups or database setup?
How to find XML-RPC usage in your codebase
Writing JSON-2 calls is the easy part. Finding every place that still uses the old ones takes far longer.
Start with a code search across every repository that touches Odoo. Look for these strings:
- /xmlrpc and /xmlrpc/2
- /jsonrpc
- execute_kw
- xmlrpc.client and ServerProxy in Python
- Ripcord or other XML-RPC libraries in PHP
- Apache XML-RPC in Java
Then look beyond code you own.
- Server logs: Check your Odoo or proxy access logs for requests to /xmlrpc and /jsonrpc. Logs show what is actually running, including scripts nobody remembers.
- Scheduled jobs: Review cron jobs, ETL tools, and reporting exports.
- Middleware: Ask automation platforms and integration tools which Odoo endpoint they call.
- Mobile apps and portals: These often log in through common and read data through objects.
The logs are the most reliable source. Code search finds what exists, while logs show what is still in use.
How to migrate from XML-RPC to JSON-2

Treat Odoo JSON-2 API migration as a small project with an owner, not a find-and-replace job. This Odoo API upgrade guide covers the steps that work for most teams.
Step 1: List every integration
Record each connected system, who owns it, what data it moves, which endpoint it calls, and how critical it is. This list becomes your migration plan.
Step 2: Sort calls by service
Group each call under db, common, or object. Calls to db need a different solution entirely. Calls to common and object map to JSON-2.
Step 3: Create a dedicated API user and keys
Set up one Odoo user per integration with only the permissions it needs. Create an API key with a clear description and a duration, and record the expiry date.
Step 4: Map each call to a JSON-2 route
Use the /doc page on your database to find the matching model and method. Turn positional arguments into named ones, and check that each response is handled correctly.
Step 5: Design for one transaction per call
Combine steps that must succeed together into a single method call, or add checks so retries do not create duplicates.
Step 6: Test on staging
Run real scenarios, including missing records, permission errors, timeouts, and repeated requests. Compare results with the old integration before switching over.
Step 7: Switch over in groups and watch the logs
Move one business area at a time. Keep the old integration ready to restore for a short period, and monitor errors closely in the first weeks.
Teams that run several connected systems often bring in an experienced Odoo development company for steps 1, 4, and 5, where most of the risk sits.
Security checks to make during the migration
Moving to JSON-2 is a good moment to clean up access. Many old integrations run with far more rights than they need, and nobody has looked at them in years.
Use the migration to fix these:
- One user per integration: Give each connector its own Odoo user, so you can see and limit what it does.
- Least privilege: Grant only the models and actions each integration needs. A reporting tool should read data, not change it.
- No admin logins: Never connect an integration through an administrator account.
- Retire old credentials: Remove the passwords and keys used by XML-RPC connectors once the JSON-2 version is live.
- Store keys safely: Keep API keys out of source code, shared drives, and chat messages.
- Log API activity: Record failed logins, permission errors, and unusual spikes in volume, so problems show up early.
How the change differs on Odoo Online, Odoo.sh and on-premise
The API change is the same everywhere. The deadline and the work involved are not.
- Odoo Online: Removals arrive about a year earlier than the numbered releases. The db service is already gone, and common and object are scheduled to go in Online 21.1. API access also depends on your pricing plan.
- Odoo.sh: Follows the numbered releases. Review custom modules, scheduled actions, and any scripts in your repositories. Use the Odoo.sh interface for backups and database copies instead of db service calls.
- On-premise: Gives you the most time until Odoo 22. It also hides the most risk, because admin scripts and old connectors often live on servers that nobody reviews.
If you are planning an Odoo 20 upgrade anyway, migrate the integrations as part of that project. Specialist Odoo migration services can cover the version upgrade and the API move together, so the business only goes through one round of testing.
Conclusion
The Odoo 20 XML-RPC API timeline gives teams a window, not a reprieve.
Odoo 20 removes the db service. Odoo 22, or Online 21.1 for cloud customers, removes the rest. Everything that still calls /xmlrpc or /jsonrpc now has a fixed end date.
Not every team needs outside help for this. If you have one or two internal scripts and a developer who knows them, that developer can move them to JSON-2 in a few days. The risk grows with the number of connectors, vendors, and people who no longer work at the company. Past that point, a structured audit is worth the time.
FAQs
Similar Blogs


Top Odoo Modules for AI & Automation: Best Apps for Business

AI dashboard builder vs custom Odoo dashboard development: which costs less long term?

Odoo Magento 2 connector: a practical guide





