Odoo and Pipedrive integration

What moves between them

Customer records (res.partner in Odoo) flow from Odoo into Pipedrive as organizations and persons. Contact sub-records create associated person records. Odoo analytic accounts map to Pipedrive deal custom fields so deal revenue allocation aligns with cost centers. Closed deals in Pipedrive are pulled back into Odoo as customer transactions or sales orders for revenue recognition. Sync runs on a schedule and targets the most recently changed records using Odoo's write_date timestamp.

How ml-connector handles it

ml-connector stores both API credentials encrypted: the Odoo API key with the instance base URL, and the Pipedrive OAuth2 token or API token. On the Odoo side, it polls for new and updated res.partner records and contact sub-records using a high-water-mark timestamp and retrieves associated analytic account codes. On the Pipedrive side, it creates matching organization and person records, maps Odoo cost centers to Pipedrive custom fields via field definitions retrieved separately, and listens for webhook events announcing deal closures. When a Pipedrive webhook arrives for a completed deal, ml-connector validates the HMAC-SHA256 signature, retrieves the full deal and organization record, and writes a corresponding Odoo customer transaction or sales order. Because Pipedrive's token budget is finite, ml-connector batches requests and respects rate limits with exponential backoff. Odoo's polling model means changes are discovered on the next sync cycle rather than pushed immediately, so pipelines are eventually consistent rather than real-time.

A real-world example

A mid-market B2B software consultancy runs Odoo for accounting, invoicing, and project cost tracking, and Pipedrive for sales opportunity management. The sales team manually searches Odoo for customer records before creating new deals in Pipedrive, and after a deal closes, the finance team re-enters the deal amount into Odoo's revenue schedule. With Odoo and Pipedrive connected, every customer created in Odoo appears in Pipedrive's organization list within the next sync cycle. Sales teams see linked cost centers and project codes from Odoo on each deal, so project margin is visible at deal close. Closed deals automatically create Odoo customer transactions for revenue recognition, eliminating the manual re-entry step and reducing month-end close time.

What you can do

• •Sync Odoo customers (res.partner) and contacts into Pipedrive organizations and persons, keeping customer master data aligned.
• •Map Odoo analytic accounts and cost centers to Pipedrive deal custom fields so sales teams see project allocation at deal close.
• •Pull closed deals from Pipedrive back into Odoo as customer transactions or sales orders for automated revenue recognition.
• •Validate Pipedrive webhook signatures (HMAC-SHA256) and handle deal closure events without polling Pipedrive continuously.
• •Respect Pipedrive's token budget and rate limits with batching and exponential backoff, and poll Odoo at a cadence that fits your sales cycle.

Questions

Can the integration handle Odoo's different deployment options (Odoo Online, Odoo.sh, self-hosted)?

Yes. ml-connector accepts the full base URL for each Odoo instance, whether Odoo Online (https://<subdomain>.odoo.com), Odoo.sh (https://<subdomain>.odoo.sh), or self-hosted. The API key and username login work across all three. Custom pricing plan or higher is required for API access.

How does ml-connector manage Pipedrive's token budget and rate limits?

Pipedrive's daily token budget varies by plan, with single reads costing 2 tokens and bulk operations costing more. ml-connector batches requests to stay within budget, tracks remaining tokens, and uses exponential backoff when rate-limit (429) responses arrive. Webhook mode for deal closure events is more efficient than continuous polling.

What happens if a deal closes in Pipedrive but the customer does not exist yet in Odoo?

ml-connector retrieves the full deal and organization record from Pipedrive and checks whether the customer exists in Odoo before writing a transaction. If the customer is missing, it either creates the Odoo customer first (if mapping is available) or returns an error and logs the failure for manual review. All actions are audited so failed records can be replayed.