The plain explanation
An API is a doorway into your system for other software.
A person uses Odoo through a browser. Another program cannot do that. It needs a defined way to ask questions — “give me all unpaid invoices” — and to make changes — “create this customer”.
That defined way is the API. Odoo has one, and it covers almost everything you can do in the interface.
For a business owner, the practical meaning is simple: your Odoo data is not locked in. Other systems can work with it, and you can automate things nobody has built a button for.
What it makes possible
Some things companies actually use it for:
- A warehouse scanner writing stock moves directly
- A payment gateway posting confirmed payments into Odoo
- A separate website sending orders in
- A reporting tool reading live sales data
- A one-off script correcting three thousand product records
- A shipping provider writing tracking numbers back onto deliveries
None of these require Odoo to have anticipated your situation. They only require that the data be reachable.
FIGURE 1: WHAT AN API CALL ACTUALLY DOES
External system
- Sends a request
Odoo checks
- Who you are and what you may do
Odoo acts
- Reads or writes the record
Response
- Data or confirmation returned
The two interfaces
Odoo offers two ways in. You do not need to choose — your developer will — but the names come up in conversations.
XML-RPC is the older interface. It is stable, well documented and works from any language. Most integrations built against Odoo use it.
JSON-RPC is the more modern interface, and is what Odoo’s own web client uses.
Both reach the same data and enforce the same rules. The choice is a technical preference, not a capability difference.
Permissions are not bypassed
This is the point that reassures most people, and it matters.
An API call runs as a user. Whatever that user is allowed to do in the interface, the API can do. Whatever they are not allowed to do, it cannot.
If your integration user has no access to payroll, no API call can read payroll. If a record rule limits a salesperson to their own customers, the API respects that too.
The practical implication: the permissions you give the integration user are the permissions the integration has. Give it the least it needs.
FIGURE 2: FOUR RULES FOR API ACCESS
Create a dedicated user
- Never use a real person’s login. When they leave, the integration should not break.
Grant the minimum access
- Only the models the integration actually needs to touch.
Use an API key, not a password
- Keys can be revoked individually without changing anyone’s login.
Log and review
- Know which integrations exist, what they do, and who owns each one.
API keys
Odoo supports API keys — a credential generated for a specific purpose, used instead of a password.
Three reasons to use them:
Revocable. If a key leaks, you disable that one key. Nobody’s login changes.
Traceable. Each key has a name, so you know which integration is which.
Compatible with two-factor authentication. A password-based integration breaks when you enable 2FA on the account. A key does not.
If a developer asks for a user’s actual password to build an integration, that is worth questioning.
What to watch for
Four things that cause problems in practice.
Rate and volume. An integration that fires a request per record will be slow and will load your server. Batching matters. If a nightly job is taking hours, this is usually why.
Error handling. What happens when Odoo is down for an upgrade, or a record is locked? A well-built integration retries and reports. A badly built one silently loses data, and nobody notices for weeks.
Version changes. Odoo’s data model changes between versions — fields get renamed, models get restructured. An integration built against version 17 may need work at version 19. Budget for this alongside your upgrade.
Nobody owning it. The most common real-world problem. An integration built two years ago by someone who has left, that everyone depends on and nobody understands.
FIGURE 3: A HEALTHY INTEGRATION AND A FRAGILE ONE
Healthy
- Dedicated user with minimum rights
- Requests batched, not one per record
- Failures retried and reported
- A named owner and written documentation
Fragile
- Runs as a real person’s account
- One request per record, taking hours
- Silent failures nobody sees
- Built by someone who has since left
Before you commission an integration
Five questions worth asking:
- What exactly will it read, and what will it write?
- Which user will it run as, and what access does that user need?
- What happens when it fails — retry, alert, or silently stop?
- Who owns it after delivery, and where is it documented?
- What will need checking at the next Odoo version upgrade?
If the answers are clear, the integration will probably last. If they are vague, you are buying something that will become somebody’s problem later.
When not to use the API
Two cases where an integration is the wrong answer.
When configuration would do it. Odoo has automated actions, scheduled jobs and email templates built in. A surprising number of “we need an integration” requests are really settings.
When the two systems should be one. If you are integrating a separate stock system with Odoo’s stock, ask whether you need the separate system at all. Every integration is a permanent maintenance cost. Removing the need for one is better than building it well.
The short version
The API is what stops your data being trapped. It is well documented, it respects your permission rules, and almost anything in the interface can be done through it.
The risks are not technical. They are organisational — integrations with too much access, no owner, and no documentation.
Get those three right and the rest is routine.
Need Odoo to talk to another system?
Get in touch. We will scope what actually needs to move, set up properly limited access, and document it so it is not a mystery in two years.
