EDI API integration for Odoo

The short answer

The EDI network or middleware receives the partner's X12 document and exposes a normalized message through an API. The Odoo-side integration validates that message, resolves the trading partner's identifiers and creates or updates the intended business record.

On the return trip, the integration reads an approved Odoo event, such as a confirmed shipment or posted invoice, builds the fields expected by the network and sends them with a stable document identity. Status and rejection messages come back into the same control loop.

Where the API sits

The boundary is easiest to reason about as three responsibilities with named owners.

• Trading-partner side

  The retailer or distributor publishes the implementation guide, document list, timing rules and test cases. Those rules remain authoritative regardless of the transport used near Odoo.

• EDI service side

  A network, VAN or middleware product receives and sends X12, handles the agreed connection, and may translate the partner format into its API model.

• Odoo side

  The connector resolves customers, ship-to locations, products, units and prices, then creates records under Odoo's access controls and business rules.

The Odoo boundary

Odoo 19 provides an external JSON-2 API at the /json/2 endpoint. Available models, fields and methods depend on the database, and Odoo exposes that database-specific surface through its /doc page. Odoo's documentation also states that external API access is available on Custom plans.

A production connector should use a dedicated integration user with the smallest practical access rights. The API applies Odoo's record rules and field access to that user, so its permissions are part of the design and part of the test plan.

A custom module can provide narrow business methods when a multi-step operation must succeed or fail as one transaction. That keeps the external caller from assembling a fragile chain of generic record writes across several models.

The current Odoo reference: External JSON-2 API.

Controls that matter in production

• Idempotency

  Every inbound and outbound document needs a stable identity. A retry should return to the same Odoo record and document state rather than create a second order, shipment or credit.

• Retry with a limit

  Temporary failures need delayed retries. Permanent mapping or business-rule failures need an exception for a person. The system should tell those cases apart.

• Status aging

  A sent document needs an expected response and an aging rule. Delivered, syntactically accepted and accepted by the receiving application are separate states.

• Traceable payloads

  Support staff need the partner document number, the Odoo record, the normalized message and every response linked in one place, with sensitive data protected by access rights.

When an API route fits

An API route is a practical fit when the EDI service already offers a supported API, the supplier runs an Odoo edition that permits the required integration, and the team needs documents to land without portal rekeying. It is especially useful when status can be retrieved alongside the business document.

AS2 or SFTP may still be the required partner-facing transport. In that design the EDI service receives the X12 connection and presents an API boundary to Odoo. The two transports occupy different parts of the route.

If the current portal volume is low and keying is controlled, a web EDI tier can remain the cheaper answer. The decision should come from document volume, exception cost and the work hidden in the manual handoff.

Compare the routes: direct AS2 or SFTP, web EDI, and the integration engagement.

Official sources

Odoo's documentation defines the Odoo API surface, while X12 publishes the transaction-set definitions. Your trading partner's implementation guide governs the fields, codes and deadlines used in your relationship.

Odoo 19 External JSON-2 API · X12 transaction sets · Our plain-language X12 catalog