HTTP Transport¶

Odoo instances natively talk to each other 1-on-1 over HTTPS.

When to Use HTTP¶

Native Odoo environments that cannot deploy additional software
Small networks that do not exchange large binary payloads
Private networks whose nodes prefer managing 1-on-1 connections with each other

For larger networks, Kubo / IPFS Transport offers superior performance and simpler credential management.

Setup Checklist¶

With demo data installed, a swarm, local node, API user, and foreign node placeholders are already created. The checklist below covers a manual setup from scratch (or filling in the demo placeholders).

Install sync_http on both Odoo instances.
On Instance A — generate your local identity: open Sync ▸ Network ▸ Peers → “HTTP Local Gateway” and click Generate Keys. (Skip if the swarm and node were created automatically.)
On Instance B — go to Settings ▸ Users ▸ API Keys, create an API key bound to a user with sync permissions (e.g. “HTTP API User”), and copy the key.
Back on Instance A — open the swarm’s Nodes tab, edit “HTTP Foreign Host” (or ▸ New). Set:
- Odoo URL — the remote base URL, e.g. https://partner.example.com
- Odoo API Key — the key you copied in step 3
Click Test Connection (action_fetch_identity()) — the remote Odoo version should appear in the server logs.
Repeat on Instance B, pointing at Instance A.

The following fields are set on each HTTP node:

Field	Description
`odoo_url`	Base URL of the remote Odoo instance (e.g. https://acme.odoo.com).
`odoo_api_key`	Bearer token used to authenticate with the remote Odoo instance.

Note

The API key is stored encrypted and visible only to the sync_manager group. The gateway uses the remote node’s own key when posting, so Instance B can match the key to a local user and apply its own access rules.

Tip

If Test Connection fails and the node stays is_online = False, check that odoo_url is reachable from inside the Odoo container (a quick curl from within the container confirms it). If events get stuck in sending with a 401 error, re-create the API key on the remote Odoo and update odoo_api_key on the node record. For self-signed TLS, add the CA certificate to the container’s trust store and restart Odoo. See Monitoring for event-level diagnostics once the connection is established.

Transport Specifics¶

Event Routing: HTTP is a synchronous push/pull mechanism. Delivery is point-to-point via REST POSTs. It is ideal for predictable, firewall-friendly topologies (e.g., Odoo nodes behind static IPs). Broadcasts are implemented using fan-out — one POST per foreign node via _dispatch_events() — and offer weak delivery guarantees (a sent event has reached the network but is not guaranteed to have reached any node).
CID Resolution: HTTP resolution is strictly “request-response.” When an event requires a blob, the receiving Odoo calls cat() on the sender’s odoo_url. Because it lacks a global DHT, the sender must be online and reachable at the time of fetch.