An API<\/strong> is a doorway into your system for other software.<\/p>\n A person uses Odoo through a browser. Another program cannot do that. It needs a defined way to ask questions \u2014 “give me all unpaid invoices” \u2014 and to make changes \u2014 “create this customer”.<\/p>\n That defined way is the API. Odoo has one, and it covers almost everything you can do in the interface.<\/p>\n For a business owner, the practical meaning is simple: your Odoo data is not locked in.<\/strong> Other systems can work with it, and you can automate things nobody has built a button for.<\/p>\n Some things companies actually use it for:<\/p>\n None of these require Odoo to have anticipated your situation. They only require that the data be reachable.<\/p>\n FIGURE 1: WHAT AN API CALL ACTUALLY DOES<\/p>\n External system<\/p>\n Odoo checks<\/p>\n Odoo acts<\/p>\n Response<\/p>\n Odoo offers two ways in. You do not need to choose \u2014 your developer will \u2014 but the names come up in conversations.<\/p>\n XML-RPC<\/strong> is the older interface. It is stable, well documented and works from any language. Most integrations built against Odoo use it.<\/p>\n JSON-RPC<\/strong> is the more modern interface, and is what Odoo’s own web client uses.<\/p>\n Both reach the same data and enforce the same rules. The choice is a technical preference, not a capability difference.<\/p>\n This is the point that reassures most people, and it matters.<\/p>\n An API call runs as a user<\/strong>. Whatever that user is allowed to do in the interface, the API can do. Whatever they are not allowed to do, it cannot.<\/p>\n 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.<\/p>\n The practical implication:<\/strong> the permissions you give the integration user are the permissions the integration has. Give it the least it needs.<\/p>\n FIGURE 2: FOUR RULES FOR API ACCESS<\/p>\n Create a dedicated user<\/p>\n Grant the minimum access<\/p>\n Use an API key, not a password<\/p>\n Log and review<\/p>\n Odoo supports API keys<\/strong> \u2014 a credential generated for a specific purpose, used instead of a password.<\/p>\n Three reasons to use them:<\/p>\n Revocable.<\/strong> If a key leaks, you disable that one key. Nobody’s login changes.<\/p>\n Traceable.<\/strong> Each key has a name, so you know which integration is which.<\/p>\n Compatible with two-factor authentication.<\/strong> A password-based integration breaks when you enable 2FA on the account. A key does not.<\/p>\n If a developer asks for a user’s actual password to build an integration, that is worth questioning.<\/p>\n Four things that cause problems in practice.<\/p>\n Rate and volume.<\/strong> 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.<\/p>\n Error handling.<\/strong> 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.<\/p>\n Version changes.<\/strong> Odoo’s data model changes between versions \u2014 fields get renamed, models get restructured. An integration built against version 17 may need work at version 19. Budget for this alongside your upgrade.<\/p>\n Nobody owning it.<\/strong> The most common real-world problem. An integration built two years ago by someone who has left, that everyone depends on and nobody understands.<\/p>\n FIGURE 3: A HEALTHY INTEGRATION AND A FRAGILE ONE<\/p>\n Healthy<\/p>\n Fragile<\/p>\n Five questions worth asking:<\/p>\n 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.<\/p>\n Two cases where an integration is the wrong answer.<\/p>\n When configuration would do it.<\/strong> Odoo has automated actions, scheduled jobs and email templates built in. A surprising number of “we need an integration” requests are really settings.<\/p>\n When the two systems should be one.<\/strong> 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.<\/p>\n 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.<\/p>\n The risks are not technical. They are organisational \u2014 integrations with too much access, no owner, and no documentation.<\/p>\n Get those three right and the rest is routine.<\/p>\n Need Odoo to talk to another system?<\/p>\n 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.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":" 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 \u2014 “give me all unpaid invoices” \u2014 and to make changes \u2014 “create this customer”. That defined way is the API. […]<\/p>\n","protected":false},"author":3,"featured_media":9104,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[25],"tags":[],"class_list":["post-9103","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-odoo"],"yoast_head":"\nWhat it makes possible<\/h2>\n
\n
\n
\n
\n
\n
The two interfaces<\/h2>\n
Permissions are not bypassed<\/h2>\n
\n
\n
\n
\n
API keys<\/h2>\n
What to watch for<\/h2>\n
\n
\n
Before you commission an integration<\/h2>\n
\n
When not to use the API<\/h2>\n
The short version<\/h2>\n