Mobile apps for Odoo field teams: standard app or custom build?

For most Odoo field teams with decent mobile signal, Odoo's own progressive web app is enough: Field Service, Barcode, Timesheets, Expenses and Attendances all work on a phone, and Odoo 19 can reopen previously viewed records without a connection. Build a custom app when people must create or change data while offline, when the workflow needs to be much simpler than Odoo's screens, or when devices such as scanners and printers need tight integration. A custom app should call Odoo's JSON-2 API with a dedicated bot user, not the older XML-RPC and JSON-RPC endpoints, which are deprecated.

What Odoo 19 gives field teams on a phone

Odoo offers two mobile apps: a progressive web app installed from the browser, and store apps on Google Play and the App Store. Odoo's documentation recommends the PWA. It supports push notifications and SSO sign-in. The store apps support multiple accounts but, per the same documentation, are not compatible with SSO. The PWA is served by the core web module, so it works on Community as well as Enterprise.

The field-relevant apps, and their editions:

• Field Service (industry_fsm, Enterprise): tasks for technicians, with worksheets through Field Service Reports, products used, timers and customer signature.
• Barcode (stock_barcode, Enterprise): receipts, picking, deliveries and counts with a phone camera or a scanning device.
• Attendances and Expenses (Community): check-in and check-out, receipt capture and submission.
• Point of Sale (Community): the one Odoo app built to keep taking orders when the connection drops, and send them when it returns.

Odoo 19 also has an offline mode for the rest of the web client. Views and records that the user opened while online can be reopened without a connection, but, in Odoo's words, they "can be viewed but not modified while offline". Odoo caps this offline data at 2 GB and drops the oldest first, and a hard refresh clears it.

When a custom app is worth building

The standard app is a full ERP client on a small screen, which is both its strength and its weakness. We recommend a custom app when one or more of these is true:

• Work happens without signal. Drivers confirming deliveries in basements, technicians in plant rooms, surveyors on farms. They need to complete jobs, capture photos and signatures, and sync later.
• The job is three taps, not thirty. A driver needs "next stop, navigate, delivered, signature, photo".
• Devices matter. Bluetooth printers for delivery slips, rugged scanners, NFC tags on assets, background location.
• The users are not Odoo users. Subcontractors or customers who should see only their own jobs through a branded app. Here, compare with Odoo's portal first; our post on Odoo portal versus a custom build covers that choice.

Keep Odoo as the system of record either way. The app is a focused client: jobs, stock moves, timesheets and attachments all land in standard Odoo models, so office staff, invoicing and reporting keep working unchanged.

Which Odoo API to build on

Odoo 19 introduced the JSON-2 API. You send a POST to /json/2/<model>/<method> with a JSON body of named arguments, and authenticate with an API key as a bearer token. Any public model method can be called this way, and every call is checked against the user's access rights, record rules and field access.

POST /json/2/project.task/search_read
Host: mycompany.example.com
Authorization: bearer <api key>
Content-Type: application/json; charset=utf-8
X-Odoo-Database: mycompany        (only if the server hosts several databases)

{"domain": [["user_ids", "in", [42]]], "fields": ["name", "partner_id", "date_deadline"]}

The older /xmlrpc, /xmlrpc/2 and /jsonrpc endpoints still work in Odoo 19, but they are deprecated. Odoo's current documentation says they are scheduled for removal in Odoo 22 (fall 2028). Anything new should use JSON-2, and existing integrations should be moved when they are next touched.

Points that shape the app's design:

• Each call is its own transaction. You cannot group several calls and roll them back together. If "complete job" must update the task, record materials and attach a signature atomically, write a small server-side method in a custom module and call that once.
• Plan matters on Odoo Online. Odoo's documentation states that external API access is available only on Custom pricing plans, not on One App Free or Standard. On Odoo.sh or your own server this restriction does not apply. Check Odoo's pricing page before designing around the API.
• Pull changes efficiently: use write_date as a change cursor and fetch only the fields you need.

Authentication and API keys

API keys are created under the user menu, My Preferences → Security → Add API Key. A key has a description and a duration, and it is shown only once. In Odoo 19, internal users are limited to keys of at most 90 days; Odoo's documentation recommends a short duration, typically one day, for interactive use, and rotation at least every three months for long-lived integration keys.

That shapes how a field app should sign in. The two sound patterns:

1. A small middleware service between the app and Odoo. Users sign in to the middleware, which holds a key for a dedicated Odoo bot user with only the rights the app needs, and exposes a narrow API: my jobs, complete job, upload photo. This is our default for field apps. Keys never reach phones, rotation happens in one place, and the middleware is where the offline sync logic lives.
2. Per-user keys issued to the device, when each worker is an Odoo user and the app talks to Odoo directly. Store the key in the Keychain or Android Keystore, give it an expiry, and build the re-authentication flow before launch, not after the first key expires in the field.

Odoo's documentation recommends dedicated bot users for automated integrations, with minimum permissions and password login disabled. Changes then show the bot as their author, so record which worker made each change in the data itself, for example on the task.

Offline for drivers and technicians

A custom field app earns its cost offline. The design is the one in our offline-first sync architecture post, applied to Odoo:

• Download the working set each morning and on every app open: assigned tasks or deliveries, customer addresses and contacts, the products and lots the worker may use.
• Record actions as events: arrived, used two units of this product, took this photo, customer signed. Events rarely conflict and map cleanly to timesheet lines, stock moves and attachments.
• Let Odoo reject what breaks rules, such as consuming stock that is not there or completing a task reassigned to someone else, and show the reason in the app.
• Upload photos and signatures separately as attachments on the record, so a slow upload does not block the job update.

If you distribute an Android app to company devices outside Google Play, note that Google's Android developer verification applies to apps on certified devices in Brazil, Indonesia, Singapore and Thailand from 30 September 2026, and globally in 2027. Register your apps before rolling out there.

Start by piloting standard Odoo with a few field workers for a couple of weeks and listing exactly where it falls short. That list becomes the app's scope. Our mobile app development and Odoo implementation teams work together on these projects, and you can contact us to go through yours.