Odoo and Rippling integration

What moves between them

The main flow runs from Rippling into Odoo. Employee records, departments, and accounting dimensions move from Rippling into Odoo so the workforce and GL cost-allocation structure stay aligned. Compensation data flows as read-only reference material to inform cost-center mappings. Changes to employees and departments in Rippling are polled at a cadence you set, typically aligned with your payroll schedule.

How ml-connector handles it

ml-connector accepts the Odoo instance base URL and API key, and the Rippling OAuth2 credentials or API key. On the Odoo side it uses JSON-2 API calls with the Bearer token to create or update employee records and cost-center associations. On the Rippling side it polls the employees endpoint with the updated_at filter and retrieves the company_activity event log to detect department and organizational changes. It maps Rippling departments to Odoo analytic accounts and cost centers, so when payroll cost allocations occur in Rippling, they reference GL dimensions that already exist in Odoo. Because both systems support high-water-mark filtering, ml-connector tracks the last-synced timestamp and fetches only new or changed records on each run, minimizing API calls and payload size. It retries failed writes and maintains a full audit trail of every employee record, department mapping, and cost-center association moved between systems.

A real-world example

A small-to-mid-market consulting firm runs Odoo for accounting and project costing, and uses Rippling for payroll and HR across multiple office locations. Before the integration, new hires required manual entry into both systems, and project cost allocation by office happened sporadically because employee department changes in Rippling were not reflected in Odoo's cost-center structure. Finance staff spent time chasing discrepancies between payroll headcount and active employees in the GL. With Odoo and Rippling connected, every new hire or location change in Rippling automatically flows into Odoo, departments are mapped to cost centers so project costs allocate correctly, and the employee roster in Odoo stays current without re-keying.

What you can do

• •Sync employees, departments, and location changes from Rippling into Odoo, keeping the workforce roster current.
• •Map Rippling departments and teams to Odoo analytic accounts and cost centers so payroll allocation dimensions are valid.
• •Authenticate Odoo with API key and Rippling with OAuth2 or API key, bridging the different credential schemes.
• •Poll employee and department changes on a schedule tied to your payroll calendar, with high-water-mark filtering to fetch only new or changed records.
• •Track every employee record, department association, and cost-center mapping in a full audit trail for replay and troubleshooting.

Questions

Which direction does data move between Odoo and Rippling?

The main flow is Rippling into Odoo. Employee records, departments, and accounting dimensions move from Rippling into Odoo to keep the workforce roster and GL cost-allocation structure aligned. Reference data such as compensation is read from Rippling to inform cost-center mappings but is not written back to Odoo.

How does ml-connector handle the different authentication schemes?

Odoo uses an API key delivered as a Bearer token in the Authorization header for JSON-2 calls. Rippling uses OAuth2 authorization code flow for App Shop integrations or direct API key bearer tokens for server-to-server access. ml-connector stores both credential sets encrypted and presents the correct auth header on each request to each system.

Does the integration require webhooks or can it use polling?

Both systems support polling with high-water-mark filtering. Odoo records carry write_date timestamps and Rippling employees have updated_at fields, so ml-connector can fetch only new or changed records on each run. This polling approach works for all Odoo editions and both OAuth2 and direct-API-key Rippling integrations without App Shop restrictions.