Skip to Content
DOC / SVC-06 - REV 01

Backend and Odoo IoT Integration

APIs, portals, dashboards, and Odoo workflows that turn a stream of device readings into something the business can actually operate on.

SVC-06 / Overview

What the backend is for

Device data has no value until something acts on it. The backend is where a reading becomes a service record, a warranty claim, a billing event, an alert to a technician, or a chart a customer logs in to see. That makes it a business-systems problem at least as much as an engineering one.

Because our own platform work is built on Odoo, we integrate device fleets directly with the system a company already runs its operations in: customers, equipment, service orders, invoicing, and inventory. Device data then lands next to the records it relates to, rather than in a separate silo somebody has to reconcile by hand.

Where Odoo is not the right home for high-rate telemetry, we keep the tiers separate: a store designed for the raw stream, and Odoo for the records and workflows that reference it.

SVC-06 / Capabilities

What this service covers

Capabilities
  • API design for devices, gateways, and apps.
  • Odoo backend models and workflows.
  • Odoo customer and portal integration.
  • PostgreSQL and SQLite data architecture.
  • User accounts, roles, and permissions.
  • Customer-facing portals.
  • Administrative portals and fleet views.
  • APNs and notification workers.
  • Data dashboards and reporting.
  • Background workers and automation.
  • Data retention and archival strategy.
SVC-06 / Method

How we approach the backend

Separate telemetry from records

A million sensor readings and a service contract are different kinds of data with different access patterns, retention needs, and consistency requirements. Storing them in the same tables works until it very abruptly does not.

We keep high-rate telemetry in a store designed for it and keep the business records, which are comparatively few and heavily related, in Odoo, with clear references between the two.

Design the API for the device, not for convenience

The client is a constrained device on an intermittent link, not a browser. That argues for batch endpoints, requests that are safe to retry, tolerance of clock skew, and payloads sized against a radio budget. An API designed purely for developer convenience tends to be expensive to talk to from a battery device.

Put the workflow where the business already is

An alert is only useful if it reaches whoever can act on it, inside the system they already work in. Integrating with Odoo means a device fault can open a service order against the right equipment and customer, rather than sending an email that someone must transcribe.

Plan retention before the first million rows

Full-resolution telemetry is worth keeping for a defined recent window and downsampling after that. The right window follows from what the business actually needs to answer. Deciding it up front is a configuration choice; deciding it later is a migration.

SVC-06 / Output

What you receive

Deliverables

  • A documented API for devices, gateways, and apps.
  • A data model covering telemetry, devices, and their business records.
  • Odoo models, workflows, and portal views where in scope.
  • Dashboards and reporting aimed at the intended audience.
  • Notification and background worker services.
  • A retention, archival, and backup policy.

When this fits

  • Device data exists but nobody in the business can act on it.
  • You run Odoo and want equipment, service, and billing linked to the device fleet.
  • Telemetry volume is growing and the current database was not designed for it.
FAQ

Questions we are asked about backend and odoo iot integration

Does the backend have to be Odoo?

No. Odoo is where we put records and business workflow, because that is usually where a company already runs. High-rate telemetry generally belongs in a store designed for it, with Odoo referencing that data rather than containing it.

Can you integrate with an Odoo instance we already run?

Yes, and that is the common case. We build standard addons against your existing database and deployment rather than replacing what you have.

How much device data should the backend keep?

Raw telemetry is usually kept at full resolution for a defined recent window and downsampled after that. The right window depends on what the business needs to answer, and deciding it up front avoids a costly migration later.

Who has access to customer device data?

Access is defined by role in the backend: end customers see their own devices through a portal, while support and administrative staff see the fleet. The model is designed with the deployment, since it usually mirrors an existing commercial relationship.

Related / Services

The rest of the stack

Connected products rarely fail in one discipline alone. These are the neighbouring layers we most often deliver in the same engagement.

IoT Hardware Design

Sensor selection, power architecture, and prototype-ready electronics.
Embedded Firmware Development

C/C++ firmware for ESP32, STM32, and Nordic nRF devices.
BLE and Wi-Fi Connectivity

Pairing, provisioning, and reliable data flow between device and cloud.
IoT Gateway Software

Fleet routing, diagnostics, and local storage at the edge.
IoT Mobile App Development

Onboarding, session control, and dashboards for connected devices.
Sense more. Do more.

Have an IoT product idea or prototype that needs a professional architecture?

Tell us what you want to build. We help transform connected product ideas into systems that sense the real world and do useful work through hardware, firmware, apps, gateways, and backend systems.

Start a Project