How the n8n and Odoo integration works
A team that wants n8n to create, update or read Odoo contacts and opportunities without manual re-entry connects the two through n8n's Odoo node or through the Odoo API called from the HTTP Request node. Which route works depends on three things: the Odoo edition you run, whether your instance grants API access, and the operations the workflow needs. Settle those before drawing any workflow, because they decide whether the work is mostly configuration or a custom build. Record the answers in writing so the design, the quote and the test plan all start from the same facts.
Licensing affects the decision before any code is written. Odoo's Community edition is licensed under LGPL-3.0, and its source is public in the Odoo GitHub repository. Odoo Enterprise source code is not publicly available and requires a subscription or partner access, so any design that depends on Enterprise-only behavior is tied to that subscription. n8n is source-available under the Sustainable Use License, which permits use or modification for your own internal business purposes and limits distribution to free, non-commercial use. Your self-hosting plan should be checked against both sets of terms, since they govern different components of the same integration.
Odoo API access is the first technical check. Odoo's pricing page states that only the Custom plan can be hosted on Odoo.sh or on-premise, and that external API access is included only in Custom. If your organization runs a different plan or Odoo Online, confirm with Odoo whether API access is available to you before you rely on the HTTP Request route. Also confirm which Odoo version your instance runs, because the model names, field names and authentication behavior your workflow depends on can change between major versions.
Do not assume which operations the Odoo node covers natively. Check the n8n node documentation for your specific n8n version, then list every create, update and read action your workflow needs for contacts, opportunities and any custom models. Mark each action as covered by the node or as needing an HTTP Request call to the Odoo API. Custom models and custom fields deserve a separate test, because a node may list a resource without exposing every field you have added. Ask for this mapping to be written down as part of the scope, so the fallback work is visible before the build starts.
Self-hosting n8n for internal workflows generally fits the internal business purpose allowance in the Sustainable Use License, but the license applies even when the Odoo side is fully open source. If you plan to distribute n8n or a product built on it to third parties, have your legal team review the license terms before go-live. Files with .ee in their name fall outside the Sustainable Use License and require a valid n8n Enterprise License, so confirm early whether your planned features depend on any of them.
What you need before connecting n8n to Odoo
Connecting n8n to Odoo depends on decisions made on both sides before any workflow is built. The Odoo edition, hosting model and plan determine whether external API access exists at all, and the n8n instance and network path determine whether it can reach Odoo. Work through these six items first.
Odoo edition and hosting model
Odoo Community is the open source edition, licensed under LGPL-3.0. Enterprise is a paid edition whose source code is not publicly available and requires a subscription or partner access. Odoo.sh and on-premise hosting both require the Custom plan, so the hosting choice fixes the plan before anything else. Community has no access to Odoo's upgrade service, which affects the version planning described below. Confirm which edition and hosting model you run before choosing an integration method.
External API access on the plan
Only the Custom plan includes external API access, along with multi-company, Odoo Studio and custom modules. The One App Free and Standard plans are Odoo Online only and do not include that access, so a team on those plans cannot call Odoo's API from n8n. Ask Odoo or your partner to confirm in writing that your subscription includes external API access before you design the workflows. Check this against your current contract, since plan inclusions can change.
Dedicated Odoo integration user
n8n authenticates to Odoo as a user, and that user's access rights decide which contacts, opportunities and custom models a workflow can read or write. Create a dedicated user for the integration and avoid reusing a personal or administrator account. Grant only the application rights and record rules each model in scope requires, and test those rights on a copy of the database first. Record who owns the account and how its credentials are rotated.
Odoo version and support end date
Confirm the Odoo major version you run and its standard support end date before choosing between the Odoo node and the HTTP Request node. Standard support covers the first three years after a major release, including security updates and bug fixes, and security patches are provided only during that period. Odoo 17.0 standard support has ended, so a system on that version needs an upgrade plan before integration work is built on it. Check the support dates in Odoo's current documentation.
Self-hosted n8n instance and version
Your n8n instance must run on servers you control, and its version should be checked against the current n8n release notes before you install or upgrade. Multi-main high availability is restricted to Enterprise self-hosted deployments, and SSO and log streaming are limited to the Business and Enterprise plans, so confirm which edition you run. Record the encryption key, because saved Odoo credentials cannot be decrypted without it. Have legal review the Sustainable Use License terms, which limit use to internal business or non-commercial purposes.
Network path and certificates
The n8n host must reach the Odoo URL over HTTPS, which means checking DNS resolution, firewall rules, proxies and any allow lists between the two systems. If Odoo uses a certificate from an internal certificate authority, the n8n host and any container running n8n must trust that chain, or requests fail during the TLS handshake. Test from the n8n host itself using the same hostname the workflows will use, since a test from a laptop does not prove the path works. Ask your network team to document both the route and the trust chain.
Native Odoo node or HTTP Request: which to use for n8n Odoo integration
Use the native Odoo node for any contact, opportunity or model operation it covers, and fall back to Odoo's API through the HTTP Request node only for operations, fields or custom models the node does not expose. Make this choice per operation, not per workflow. A single workflow often mixes both, and that is fine as long as each HTTP Request call has a stated reason for existing. The native node is the simpler option to maintain. Parameters, credential fields and error handling come from the node package, and you get them updated through normal n8n upgrades. The HTTP Request node gives full control over the call, including the model, method, fields and domain filters you send to Odoo. That control has a cost. Your team builds and tests every request, parses every response, handles authentication and errors, and decides how retries behave when Odoo rejects a record or times out.
Most of the ongoing risk on the HTTP Request path is version drift. Odoo releases SaaS versions every two to three months, and each major version has its own standard support window. A field name, a required value or a model's behavior can change between versions, and nothing in n8n will warn you when a hand-built call stops matching the schema. Odoo's standard support for 19.0, released in September 2025, runs until September 2028, and 17.0 standard support has already ended. Plan a test pass against the Odoo version you run whenever Odoo is upgraded, and keep the same test pass for n8n upgrades. Before you design any fallback, confirm that your Odoo plan includes external API access. Odoo's pricing page states that only the Custom plan includes external API access, along with multi-company, Odoo Studio and custom modules. If your organization is on another plan, the HTTP Request path may not be available at all, and the native node or an alternative integration method becomes the only option. Ask Odoo to confirm this in writing for your edition and hosting model, because plan terms change.
Check the operation list in the Odoo node of your exact n8n version before you commit to a design. Coverage changes between releases, and n8n ships minor releases roughly weekly, so a fallback you built last quarter may now be unnecessary. Record which native operations you tested, which Odoo models and fields you need, and whether each one works against your Odoo version. Do not rely on a list from documentation written for an older release. Document every HTTP Request fallback as a deliberate decision. For each one, record the workflow name, the Odoo model and fields it touches, the reason the native node does not cover it, the n8n and Odoo versions it was tested against, the team member who owns it, and the test steps to rerun after an upgrade. Undocumented fallbacks are the ones that break silently during an upgrade and are hardest to explain to an auditor or a new engineer.
Review the register at each n8n and Odoo upgrade, and remove any fallback that the native node now covers. Treat the review as part of the upgrade plan, not as an optional cleanup. A short register also makes the trade-off visible to leadership, because it shows how many workflows depend on hand-built API calls and who is responsible for keeping them working. If that number grows, it is a signal to reassess the integration design rather than to keep adding calls.
How to configure the n8n Odoo credential and first workflow
This sequence takes an n8n instance from a confirmed Odoo API connection to a tested read and a tested write, using a dedicated integration user and a separate test database. Each step closes with a check you can verify in both systems before you build anything on top of the credential.
Confirm Odoo API access for your edition
Your Odoo administrator confirms that the instance offers external API access for the edition and plan in use. Odoo's pricing page lists external API access among the features included only in the Custom plan, so check the subscription before anything else. Record the instance URL, the database name and the login method the instance expects. This step is done when a simple API call made outside n8n, such as a short script run from a machine on the same network path n8n will use, returns a user ID for the account you plan to use.
Create a dedicated integration user
The Odoo administrator creates a separate service user for n8n and does not reuse a personal account. Assign only the access rights the planned workflows need, starting with read access to contacts. Add write rights to specific models only when a named use case requires them, and keep the user out of administrator groups. Document which models and fields the user can reach. This step is done when a review of the user's access rights matches the written list and the user cannot open any model outside that list in the Odoo interface.
Create the credential in n8n
An n8n administrator opens the credentials area and creates an Odoo credential for the integration user. n8n stores credential data encrypted in its database using the instance encryption key, so back that key up securely and keep it out of workflow exports. Confirm the exact field names and authentication options in the Odoo node UI for the n8n version you run, because fields can change between releases. This step is done when the credential saves without error and appears in the credentials list with no secret visible in the interface.
Set the database name, URL and login
Enter the database name, the base URL and the integration user's login exactly as the Odoo instance expects them, including the protocol and any path prefix. Copy the database name from the database selector or the administrator settings rather than from memory, and confirm with your Odoo administrator whether it is case-sensitive. Enter the password or API key issued to the integration user. This step is done when a first simple node execution authenticates and returns data without an authentication error.
Run a read-only test on a contact
Build a workflow with a manual trigger and one Odoo node set to read contacts, filtered to a single record your team knows exists, such as a test contact created for this purpose. Run it once and compare the returned fields with the same record opened in the Odoo interface. Confirm the workflow contains no write operations. This step is done when the output matches the record ID, name and email shown in Odoo. Keep this workflow as the baseline you rerun after any change to the credential.
Add a write test in a test database
Create a copy of the production database in a separate test environment using the duplication with neutralization option Odoo documents for test copies. Neutralization is meant to keep a copy from acting on real data, so confirm in your Odoo version what it disables before you rely on it. Point a credential at the test database and add a create operation for one test contact. This step is done when the new record appears in the test database's Odoo interface, and a follow-up update and archive also succeed. Do not run write tests against production.
Align queue mode workers with the encryption key
If the n8n instance runs in queue mode, every worker and webhook processor must use the same encryption key as the main instance, because workers read credentials from the shared database. Copy the key to each worker configuration through a secure channel, restart the workers, and do not generate a new key on a worker. Repeat this check after any change to the worker pool. This step is done when a workflow using the Odoo credential completes on a worker, which you confirm in its execution record.
How contacts, opportunities and custom models map between n8n and Odoo
This table pairs each n8n field or item property with the Odoo model and field it writes to, for contacts, opportunities and one custom model. Read each row left to right: the n8n property, the Odoo target, the data type and requirement, then the source of truth and duplicate or relation rules. Confirm every technical name in your Odoo version, and treat the custom model rows as provisional until your custom modules are installed.
| n8n field or item property | Odoo model and field | Data type and requirement | Source of truth and duplicate or relation notes |
|---|---|---|---|
| Contact name | res.partner, field name | Text, required when creating a contact | Source: CRM or customer master. Confirm the naming rule with the business before mapping. |
| Contact email | res.partner, field email | Text, optional but used as the match key | Source: customer-facing system. Normalize case and whitespace before searching for an existing contact. |
| Company link | res.partner, field parent_id | Reference to a company contact, optional | Many contacts can point to one company. Find or create the company record before its employees. |
| Opportunity title | crm.lead, field name | Text, required | Source: sales team. Titles are not unique, so store an external reference if your Odoo has a field for it. |
| Opportunity stage | crm.lead, field stage_id | Reference to a stage record, required by your pipeline | Agree stage names with sales before mapping. Look up the stage record by name and store its ID for reuse. |
| Opportunity owner | crm.lead, field user_id | Reference to an Odoo user, optional | Source: sales management. Agree the ownership rule with the business before mapping any automation. |
| Opportunity contact | crm.lead, field partner_id | Reference to a contact, optional | Many opportunities can link to one contact. Pass the contact ID matched in the contact flow. |
| Custom model field | Your custom model and field names (x_ prefix in many setups) | Depends on the field definition | Exists only where the custom module is installed. Confirm model and field names in developer mode. |
Securing the Odoo credential and API access in n8n
The n8n Odoo node is only as secure as the Odoo account and n8n secrets behind it. These controls cover who the integration runs as, how n8n stores and shares its credentials, which network paths stay open, how API activity is recorded, and which identity choices must be made first. Confirm each setting against your own security baseline before the first production workflow runs.
Dedicated Odoo integration user
Create a separate Odoo user for n8n and avoid reusing a personal or administrator account. Its credential then belongs to the integration, can be rotated without affecting staff, and its actions are easy to tell apart in Odoo's records. Limit its access rights to the models and operations the workflows need, such as contacts, opportunities and any custom models, and review that list whenever a workflow changes. External API access is part of Odoo's Custom plan, so confirm your edition covers the access path you choose.
Credential encryption and key handling
n8n encrypts stored credentials with an encryption key from the main instance. In queue mode, that same key must also be available to every worker and webhook processor, because those processes read credentials from the database. Decide how the key is generated, stored, distributed to each process and backed up before rollout. Restoring a database without the matching key leaves the Odoo credentials unusable, so include the key in your recovery plan and confirm the rotation steps against your baseline.
Limiting who can open credentials
Anyone who can open the Odoo credential in n8n can use it in their own workflows and, depending on their role, may be able to view its details or export workflows that reference it. Assign roles deliberately, keep the Odoo credential out of personal spaces, and confirm for each role whether exporting workflows or credentials is allowed. Check which role and sharing controls your n8n edition provides, then test the restrictions with a non-admin account before go-live.
Network paths between n8n and Odoo
Decide which hosts can reach the Odoo web and API endpoints, and allow only the n8n main instance, workers or webhook processors that need them. The integration should use the application API, so keep the Odoo database port closed to n8n. If n8n runs in a different cloud account, data center or network segment, document each firewall rule and routing path, then test that connections from other sources are refused. Confirm the ports and TLS settings in your own environment.
Logging API calls on both sides
Record activity in both systems so an incident can be traced end to end. In n8n, the execution history shows which workflow ran, when it ran and which credential it used. In Odoo, review the server logs and any audit features your edition provides for the integration user. Check retention on each side, limit who can read the logs, and mask secrets and personal data in payloads. Log streaming from n8n is included only in the Business and Enterprise plans, so confirm which options your plan supports.
Identity choices before rollout
Decide how people sign in to n8n and how Odoo authenticates users before go-live, because changing identity later affects accounts, credentials and role assignments. SSO and LDAP for n8n are included only in the Business and Enterprise plans, and n8n publishes SAML setup guides for Okta Workforce Identity and Azure AD. Odoo documents LDAP authentication, so decide whether Odoo users, the integration user and n8n users will share one directory. Confirm which options your plan and edition support.
How to test an n8n Odoo workflow before production
Build and test every n8n Odoo workflow against a database copy that is separate from production. Odoo documents database duplication with neutralization for on-premise test copies, and neutralization is the step that stops the copy from behaving like production. Confirm in the Odoo on-premise documentation for your version exactly which settings the neutralization resets, such as outgoing mail servers, scheduled actions and external service configuration, then check those settings by hand after the copy is created. Without that check, a workflow that creates a contact or updates an opportunity can send an email to a live customer or call a live messaging or payment integration. Agree a refresh schedule with the business owners and record the date each copy was taken, so test results can be tied to the data they ran against.
Cover four paths for each workflow: create, update, search and error. For create, submit a new contact with all required fields and confirm that exactly one record appears. For duplicates, run the search step first with a contact that already exists and confirm that the workflow routes the matching item to review and creates no second record. For missing required fields, remove one required field from the payload and confirm that the error branch catches Odoo's rejection, logs the input details and sends nothing downstream. For access rights, run the workflow with an integration user that has one model permission removed, and confirm that the denial is handled with a clear log entry rather than a silent failure. Add update and search cases for records that exist, records that do not exist and searches that match more than one record.
Verify results inside Odoo, beyond the n8n execution log. An execution marked successful shows what the node returned, but it does not prove that the record landed with the right values. Open each affected record in the Odoo interface, compare field values with the input, and check the chatter or message history for notifications nobody expected. Look in the outgoing mail queue to confirm that nothing was sent, and confirm that changes are attributed to the test integration user rather than an administrator account. Keep a short expected-results sheet for each test case, so a reviewer can repeat the same checks after every change to the workflow or to the Odoo version underneath it.
Keep test and production credentials apart at every layer. Create a separate n8n credential for the test database that points to the test Odoo address and uses a dedicated test integration user, and name it so the environment is obvious on the canvas. Do not reuse the production credential by changing only the address in a copied workflow. If your team runs a separate n8n instance for testing, give it its own encryption key, because queue mode requires the main instance key to be shared with its workers, and that sharing should stay inside one environment. If you plan to manage environments through Git, confirm first that your n8n plan includes it, since the pricing page places environments with Git only in the Business and Enterprise plans. Attach production credentials only at deployment, after the same test cases pass against the test copy.
Common n8n Odoo integration failures and how to fix them
This table lists six failure points that appear when n8n connects to Odoo, with the likely cause and the first check or fix for each. Read it from the symptom column outward, and start with authentication and access rights before debugging field mappings or retries. Confirm every fix against the Odoo and n8n versions in use, because field names, credential handling and node behavior can change between releases.
| Symptom | Likely cause | Check or fix |
|---|---|---|
| Authentication fails with a database or login error | Wrong Odoo database name, wrong login, or the API key was not used in place of the password | Confirm the exact database name on the database selector, then test the same login and key in the credential |
| Access denied on a specific model | The Odoo user lacks read, create or write rights on that model, or a record rule filters the records | Review the user's access rights and record rules for the model, then repeat the call with the same user outside n8n |
| Native node cannot set or read a needed field | The node's operation does not expose that field, often a custom field or one added by an installed module | Make that call with the HTTP Request node using the same credential, after checking the field name on the model |
| HTTP Request calls fail after an Odoo upgrade | A field or model was renamed, removed or changed type in the new Odoo version | Compare field names in the upgraded test database with the workflow, update the expressions, then retest before production |
| Credentials work in manual runs but fail in queue mode workers | The encryption key on the main instance is not identical on every worker and webhook processor | Set the same encryption key on all workers and webhook processors, restart them, then rerun a test execution |
| Duplicate records after a retried execution | A run that failed or timed out after Odoo created the record is retried and creates it again | Search for an existing record by a stable reference before create, and store the Odoo record ID so retries reuse it |
Keeping the n8n Odoo integration working through upgrades
The n8n Odoo integration depends on two upgrade streams that move on different schedules, so a change in either one can break workflows that worked the week before. Odoo standard support covers three years after a major release, including security updates and bug fixes. Odoo 19.0 has standard support planned until September 2028, while Odoo 17.0 standard support ended in September 2026. Any database still on 17.0 and feeding n8n no longer receives security patches under standard support. Start by listing every Odoo database the workflows touch, its major version, and the end date of its standard support, then set a target version for each one.
Odoo Online and Odoo.sh require major upgrades every two years, so the team cannot defer them indefinitely on those hosting models. Odoo's upgrade service moves a database to a newer supported version through an upgraded test database, which should be tested before production is switched over. On-premise databases can use the upgrade service only with an Enterprise subscription, and the Community edition has no access to it. Before each major upgrade, plan an Odoo upgrade test database: duplicate production, use the documented neutralization for test copies so scheduled actions and outgoing mail do not reach live contacts, then point a staging n8n instance at that copy. Confirm the neutralization steps cover every setting your workflows depend on.
n8n uses semantic versioning and ships minor releases roughly weekly, so an unpinned installation can change underneath the workflows without anyone deciding it should. Pin a tested n8n version in the deployment definition, whether that is a container image tag or a package version, and move it only through a staging instance. Before each upgrade, read the n8n release notes for the target range and confirm whether any breaking changes affect the Odoo node, the HTTP Request node, credential handling or expression behavior. Record the pinned version next to the Odoo version in your change log, so that a failed upgrade can be rolled back to a known pair.
After any upgrade on either side, retest the workflows instead of assuming they still run. Cover the Odoo node operations your processes use for contacts, opportunities and custom models, and the HTTP Request calls that go to Odoo's API for anything the node does not cover. Use a small regression set with known input records and expected results, including one failure path such as an expired credential or a missing record. Odoo major versions can change model fields and API behavior, so check the release notes for the target Odoo version against each field name and endpoint your HTTP Request nodes use. Assign one owner to sign off the results before production moves.
Questions buyers ask before hiring help for n8n Odoo integration
What drives the cost of an n8n and Odoo integration?
Cost depends on the operations in scope, the number of custom models, how many steps fall back to the HTTP Request node, the Odoo edition and API access, the n8n plan and hosting, and the number of environments. Operations the n8n Odoo node covers natively need less build work than raw Odoo API calls, and each custom model adds mapping, testing and documentation. Costs split into one-time work (design, build, testing, handover) and recurring items (hosting, n8n and Odoo subscriptions, support retainers). Ask for a written scope and quote that lists each cost component and who is paid for it, including whether your Odoo plan covers the API access the design needs.
How long does it take to scope and build this integration?
Duration depends on the written scope, so ask for milestones before you ask for a number: discovery, design sign-off, build, test, go-live and handover. The scope phase grows with the number of Odoo objects, approval rules and connected systems that must be mapped. The build phase grows with the number of custom models, HTTP Request fallbacks, error paths and environments that must be tested. Delays often come from waiting on process owners and test data rather than from the technical build, so agree on response times for those people. Plan time for a test database in Odoo before production, and confirm with the partner which tests each milestone requires.
What must our team provide before an integration project starts?
Your team needs to provide access and people, not only a project brief. Provide an Odoo user with API permissions for the models in scope, plus a test database that is separate from production. Provide sample records that reflect your contacts, opportunities and custom models, with sensitive fields handled according to your policy. Name a process owner for each workflow who can settle business rules and approve test results. Provide an n8n environment for development, access to credential owners, and a change window for go-live. Confirm these items in the written scope so that delays have a clear owner.
Can an in-house team build the n8n Odoo integration itself?
Yes, an in-house team can build it if it already runs n8n and Odoo and has someone who understands Odoo's data model and API permissions. The basics are learnable: credentials, node configuration, webhooks, error handling and HTTP Request calls. The harder parts are operational. Teams must keep the n8n encryption key consistent across queue-mode workers, decide which operations stay native, manage Odoo upgrades, and document who owns each workflow. Compare the people who would design, build, test and run the integration with a written partner scope. The comparison shows whether the gap is build capacity, Odoo expertise or ongoing ownership.
Does the Odoo edition affect what we can automate through the API?
Yes. According to Odoo's pricing page, external API access and custom modules are included only in the Custom plan, and only the Custom plan can be hosted on Odoo.sh or on-premise. The Community edition is open source under LGPL-3.0 and has no access to Odoo's upgrade service. Enterprise on-premise databases require a subscription code. If your design depends on API access, confirm with Odoo which plan, edition and hosting model include it before the scope is signed. Check this against the current pricing page, because plan details can change and the page is the source to rely on.
Which n8n plan does a production Odoo integration need?
The Community edition is free to self-host, but it lacks several features that production teams often need. According to n8n's pricing page, SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans. Starter and Pro are cloud plans listed at 20 euros and 50 euros per month billed annually. Business is listed at 667 euros per month billed annually and is currently self-hosted only. Enterprise is custom priced and is the only plan that offers multi-main high availability for self-hosted deployments. Queue mode requires the encryption key to be shared with all workers. Confirm the license terms for your intended use under the Sustainable Use License.
When does an Odoo integration need the HTTP Request node?
Use the HTTP Request node when the n8n Odoo node does not cover an operation or custom model you need, and call Odoo's external API directly with authenticated requests. This path is flexible, but your team owns the request structure, field names, pagination, error handling and tests. Each fallback adds maintenance, because a change in Odoo's models or API behavior can break a call that the native node would have handled. Ask the partner to list which operations are native in your n8n version, which need fallbacks, and how each fallback will be tested after platform upgrades.
What changes after go-live, and who maintains the integration?
After go-live, the integration needs the same care as any production system. Odoo SaaS versions are released every two to three months, and on Odoo Online and Odoo.sh major upgrades are mandatory every two years, so models and API behavior can change. n8n ships minor releases roughly weekly, and major versions can bring breaking changes. Recurring work includes credential rotation, monitoring of failed executions, access reviews and test runs after each upgrade. Ask whether the scope includes handover documentation, a support retainer and a named owner for each workflow, and whether the partner's responsibilities end at handover or continue.
How DeployOpen scopes and delivers the n8n Odoo integration
DeployOpen plans, builds, documents and supports n8n and Odoo integrations inside your own infrastructure, whether that is your cloud account, data center or air-gapped network. Work starts from a written, fixed scope that names the Odoo models, n8n nodes and fallback API calls involved. Ongoing support, upgrades and continuous testing are available as a retainer.
How we scope
- Confirm the Odoo edition, plan and hosting, since external API access is limited to the Custom plan.
- Map each Odoo model, such as contacts, opportunities and custom models, to the n8n operations that touch it.
- List which operations the n8n Odoo node covers natively and which steps fall back to HTTP Request calls.
How we build
- Create Odoo credentials with the least access each workflow needs, and store them in n8n's credential store.
- Build the native node flows first, then add HTTP Request steps only where the node lacks an operation.
- In queue mode, share the main instance encryption key with every worker and webhook processor node.
How we hand over
- Test against a duplicated Odoo database with neutralization, so workflows never write to live records during testing.
- Document each workflow, its Odoo model mappings, credential owners and the fallback calls it uses.
- Hand over runbooks for credential rotation, workflow changes and Odoo upgrade impact on API calls.
How we support
- Plan around Odoo version timing, since Odoo Online and Odoo.sh require major upgrades every two years.
- Retest n8n workflows after each n8n minor release and before any planned major upgrade in your environment.
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing.
