Odoo reaches carrier, payment, and supplier APIs that filter by source address, and Odoo.sh instance IPs are documented to change. Send the Python process's outbound traffic through two static EU IPs and every allowlist stays valid.
# on the Odoo server process
HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
import requests
# rate lookup now leaves from your fixed IP
requests.post('https://api.carrier.eu/rates',
json=shipment_payload)
Odoo centralizes your logistics and finance integrations in one server, then hosts that server on infrastructure whose outbound address is anything but permanent.
Odoo's hosting FAQ states that a project's address shifts during architectural migrations, roughly every two years, and again after any disaster recovery. On standard plans the platform may move it whenever capacity requires. Each shift silently invalidates every partner allowlist that named the old address.
Odoo.sh can notify project admins and fire a webhook when the instance IP moves, so teams wire up scripts to push the new address to each partner. That is cleanup after the outage, not prevention: between the change and your script running, rate lookups and label purchases are rejected.
A single Odoo install talks to carrier connectors like UPS, FedEx, and DHL Express, payment acquirers, bank synchronization services, and supplier portals. Several of those partners grant access by IP, which multiplies the number of places a changed address breaks something.
A rejected carrier call does not return an error page to an engineer. It appears at the packing station when a warehouse operative tries to print a label, or weeks later when reconciliation spots a bank sync that quietly stopped. The ERP keeps running; the workflow jams.
Odoo server
Python, any host
HTTPS Proxy
(Static EU IP)
Carrier / partner API
IP allowlist enforced
Partners see one thing only: your requests arriving from the same two European addresses, whether Odoo runs on Odoo.sh, a dedicated server, or your own Kubernetes cluster. Whichever node answers, the source stays inside the pair you registered.
HTTPS_PROXY where the Odoo process starts and every connector built on requests inherits it, no module edits needed.Shipping, invoicing, and custom modules all leave through the same exit, so there is one integration to maintain instead of one per partner.
When the platform migrates your project or recovers it in another region, partners keep seeing your registered pair and nothing breaks for the warehouse.
Odoo comes from a Belgian vendor and your data is EU-heavy; routing egress through European nodes keeps that story consistent.
Odoo deployments whose partners answer only to addresses they recognize.
Warehouses printing labels and pulling live rates through UPS, FedEx, or DHL Express connectors where the carrier portal gates access by IP.
Teams whose bank synchronization feeds and payment acquirer callbacks depend on endpoints that only accept registered addresses.
Operators who want one egress policy for the whole Odoo stack instead of patching proxy config into every custom addon.
Companies whose ERP moves customer and supplier records between systems and must document that the path stays inside the Union.
Odoo's Python stack speaks requests, which reads HTTPS_PROXY from the environment on its own. One variable, set where the server starts.
Set the proxy in the Odoo service definition (or /etc/environment), restart, and every module using requests inherits the fixed exit.
# /etc/systemd/system/odoo.service
[Service]
Environment=HTTPS_PROXY=https://user:pass@eu-01.outboundgateway.com:8443
ExecStart=/opt/odoo/odoo-bin -c /etc/odoo.conf
# reload and restart
systemctl daemon-reload && systemctl restart odooContainerized Odoo picks the variable up the same way. Keep credentials in a .env file, never inline in the compose file.
# docker-compose.yml
services:
odoo:
image: odoo:19
env_file: .env # contains HTTPS_PROXY=...
ports:
- "8069:8069"For per-call control, pass the proxy in your own module and store the URL as a System Parameter under Settings, Technical, System Parameters.
# custom_addons/carrier_sync/models/carrier_sync.py
import requests
from odoo import models
class CarrierSync(models.Model):
_name = "carrier.sync"
def push_shipment(self):
proxy_url = self.env["ir.config_parameter"].sudo().get_param(
"outboundgateway.proxy_url")
requests.post(
"https://api.carrier.eu/shipments",
json=self._prepare_payload(),
proxies={"https": proxy_url},
timeout=30,
)Put the pair on every partner portal
An account includes two static EU addresses, and the second exists precisely for the day the first needs maintenance. Add both to each carrier and bank portal; failover then happens behind the scenes with no ticket, no script, and no interrupted label run.
📖 Complete Documentation: For detailed examples, error handling, and advanced configurations, see the all guides.
An ERP knows your customers, your prices, and your bank accounts. Where its traffic exits is part of your compliance story.
Customer records and payment details travelling from a European ERP to European partners stay within Union boundaries the whole way.
Connections to carriers and banks are never decrypted in transit; the proxy forwards sealed traffic and sees nothing it could read.
Two European addresses, each ready to carry the load if its partner node pauses.
One environment variable covers every requests-based connector; drop to per-call proxies= only if you ask for it.
Sealed TLS passes the proxy untouched, keeping shipment and payment payloads private.
An EU exit that pairs naturally with Odoo's Belgian roots and an EU-hosted database.
Carriers, acquirers, banks, and supplier portals all see the identical address pair you registered.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
Register two static EU addresses with every carrier and bank, set one variable on the Odoo process, and platform migrations stop being an integration event. Starting is a form away.
Starting from €19/month. Flexible plans for every scale. Cancel anytime.
No. The Odoo.sh FAQ documents that a project's address changes with architectural migrations, roughly every two years, and after disaster recovery, and standard hosting can move it as the platform requires. Odoo.sh notifies admins and can trigger a webhook when it happens, but by then partners holding the old address have already started rejecting you. A proxy decouples your registered address from wherever Odoo happens to host you that week.
Odoo is a Python server, and its connectors plus most custom code issue HTTP through the requests library, which reads HTTPS_PROXY from the process environment automatically. Set the variable where the service starts, on a systemd unit or in the container definition, and it applies across the board. When you want tighter control, or you are on Odoo.sh, pass proxies= per call in your module and keep the URL in an ir.config_parameter entry.
Both of yours. Each account carries a pair of static EU addresses precisely so the second can take over without a support ticket; listing only one reintroduces the single point of failure you are trying to remove. Register the two together and failovers pass completely unnoticed on the partner side.
Glad to talk through your hosting setup, your carrier list, and whether a fixed EU pair fits how your integrations are wired.
Contact Our Founders →