Read-Only vs. Write-Back Odoo Integrations: Which Do You Need?

A read-only integration only ever queries Odoo, using calls likesearch, search_read, andread_group, and never calls anything that creates, updates, or deletes a record. A write-back integration does one or more of those things: it might create a new sale.order, update a field on an existing record with write, or call a business method that changes a record's state, like confirming a purchase order or validating a stock transfer.

A bug in a read-only integration produces a wrong number on a screen somewhere (annoying, and worth fixing), but it never touches Odoo's actual data, so it's fully recoverable by just fixing the query. A bug in a write-back integration can create a malformed sales order, wrongly confirm a stock move that shouldn't have gone through, or write incorrect values directly into records that accounting, other staff, and other automations then rely on as if they were entered correctly by a person. That's a meaningfully higher bar, and it's why write-back work is scoped and built more carefully.

Validating input before it's sent to Odoo, rather than letting Odoo's own error be the first check. Calling the correct higher-level business method (for example, the same action Odoo's "Validate" button triggers on a stock transfer) instead of writing raw state fields directly, so Odoo's own business logic and side effects still run as intended. Handling partial failures explicitly: what happens if an order has five lines and the fourth one fails Odoo's own validation? And keeping a clear, reviewable record of what the integration actually created or changed, so a problem can be traced back to a specific call instead of guessed at.

No. Most real apps are a mix of both, applied per action rather than per app. A mobile sales app, for instance, reads stock levels and pricing (read-only) and then writes a new order on submit (write-back). The two patterns coexist inside one app; what matters is being deliberate about which specific action is which, rather than treating "the app" as a single monolithic risk level.

Write-back work generally costs more than an equivalent read-only feature, because of the extra validation, error-handling, and testing it needs to be done responsibly, not because the API call itself is harder to make. See the guide on custom Odoo app cost, linked below, for how this plays into overall pricing.

Ask, for each specific screen or action: does this need to change something in Odoo, or only show something? If it's purely informational (a dashboard, a report, a status lookup), it's read-only. If someone needs to submit, confirm, approve, or record something that should end up as a real Odoo record, it's write-back. Most projects turn out to need a specific, identifiable mix of the two rather than being purely one or the other.