Astro and Odoo make an effective pair for content-heavy sites: Odoo supplies an operational editor, while Astro supplies a fast, purpose-built public experience. The important design work happens at the boundary between them.
Start with the trust boundary
The public frontend should never receive an Odoo administrator password or unrestricted database access. It needs one narrow capability: read approved public records.
GET /portfolio/api/site
X-Portfolio-Token: <separate integration secret>Keeping this secret separate from the Odoo login password makes rotation and revocation straightforward. The Astro service can call Odoo over a private container network, so the integration endpoint does not need to be part of the public attack surface.
Return an explicit publication shape
Do not expose generic ORM records directly. Build a stable response containing only the fields the frontend renders: profile, published projects, public blog posts, and other approved sections.
The integration is a product boundary, not merely a serialization helper.
Design for failure
The frontend can fall back to a small bundled profile when the content service is unavailable. This keeps the site readable while making degraded content visible in server logs.
- Use a short request timeout.
- Log backend failures without secrets.
- Validate response shape at build time.
- Keep unpublished records out of every response.
Caching comes after correctness
Once publication state is reliable, add short-lived caching and explicit invalidation. Optimizing an endpoint that leaks draft content is not an optimization—it is risk amplification.