Odoo API Integration: The Right Architecture vs the Common Shortcuts
Most Odoo integrations are built as direct point-to-point connections. They work on the day they are deployed. They do not survive a token refresh at 3am, a rate limit response, or a payload format change.
The Service-Layer Pattern
Every integration built on the Stratum Framework uses a service-layer architecture. The integration logic lives in L2 (Base Architecture Module), not in L3 (Implementation) or directly in Odoo views.
This means:
- Authentication is isolated per integration
- Every external call has retry logic with exponential backoff
- Failures are logged with structured context: timestamp, endpoint, payload hash, response code, retry count
- Token refresh happens automatically without interrupting active workflows
Authentication Isolation
Each integration has its own credential store, its own token lifecycle, and its own error handling. A failure in the WhatsApp integration does not affect the Field Nation integration.
Retry Logic with Exponential Backoff
Every external API call is wrapped in a retry handler. First retry after 1 second, then 2, then 4, with jitter. After maximum retries, the failure is logged with full context and an alert is generated.
The Common Shortcuts (and Why They Break)
The shortcuts most developers take: hardcoded credentials, no retry logic, silent failures, shared authentication, and direct model writes without validation.
Each of these works in testing. Each of them fails in production.