Zoho Books and Microsoft Dynamics 365 Sales integration

What moves between them

Customer and invoice data flows from Zoho Books into Microsoft Dynamics 365 Sales. Zoho Books contacts are mapped to Dynamics 365 Sales accounts, creating new account records or updating existing ones based on a unique match field. Invoices are mapped to Dynamics 365 Sales orders and invoice records. The integration runs on a schedule you control, reading from Zoho Books via REST polling and writing to Dynamics 365 Sales via OData. Billable transactions, expenses, and purchase orders stay in Zoho Books; Dynamics 365 Sales records are kept current but do not flow back to Zoho Books.

How ml-connector handles it

ml-connector stores both credential sets encrypted and routes Zoho Books API calls to the correct regional base URL determined by the region field in the OAuth token response. It refreshes Zoho Books access tokens proactively before they expire and caches the organization ID for every call. On the Dynamics 365 Sales side it refreshes the Entra ID bearer token and presents it on every OData request. Because Zoho Books rate limits to 100 requests per minute, ml-connector backs off and retries on 429 responses. Contacts are matched by email address or phone number first; if no match is found, a new account is created in Dynamics 365 Sales. Invoices are matched to orders via a reference number or invoice ID field mapped from Zoho Books. Every record carries a full audit trail, and failed writes are queued for replay when the downstream call is retried. Both platforms support webhooks, but ml-connector can also poll on your chosen schedule if webhook delivery is not available in your region or plan.

A real-world example

A mid-sized B2B SaaS company runs Zoho Books for invoicing and accounting and uses Microsoft Dynamics 365 Sales to manage enterprise customer relationships and sales pipeline. Before the integration, the sales team manually entered new customer records from Zoho Books invoices into Dynamics 365 Sales and re-entered invoice amounts when they closed deals. The finance team had to reconcile customer lists and outstanding invoices across both systems at quarter-end close. With Zoho Books and Dynamics 365 Sales connected, customer records sync automatically when an invoice is created, and the sales team sees real-time invoice and payment history on every account. Quarter-end close starts with customer data already aligned across both systems, and the manual reconciliation is eliminated.

What you can do

• •Sync customer records from Zoho Books to Microsoft Dynamics 365 Sales accounts, creating new account records or updating existing matches based on email or phone.
• •Sync invoice data from Zoho Books to Dynamics 365 Sales orders and invoice records, preserving invoice amounts and due dates.
• •Route Zoho Books API calls to the correct regional base URL and manage 100 requests-per-minute rate limits with exponential backoff.
• •Authenticate Zoho Books with OAuth2 and refresh tokens, and Dynamics 365 Sales with Microsoft Entra ID client credentials.
• •Run on a polling schedule you define, with full audit trail and automatic replay of failed records.

Questions

Which direction does data move between Zoho Books and Microsoft Dynamics 365 Sales?

The main flow is Zoho Books into Dynamics 365 Sales. Customer contacts and invoices move from Zoho Books into Dynamics 365 Sales accounts and orders. Dynamics 365 Sales does not write back to Zoho Books; revenue transactions remain the source of truth in Zoho Books.

How does ml-connector handle Zoho Books' regional base URLs?

Zoho Books returns the region field in the OAuth token response and publishes region-specific base URLs for the US, EU, India, Australia, Japan, Canada, China, and Saudi Arabia. ml-connector stores the region with the credential set and routes every API call to the correct regional endpoint determined by that credential. This ensures compliance with data residency requirements.

What happens when Zoho Books rate limits to 100 requests per minute?

ml-connector tracks the rate limit by monitoring HTTP 429 responses and backs off with exponential retry timing. Scheduled syncs may slow down or queue requests if the limit is reached, but no data is lost. Retries are automatic, and the audit trail shows which records were rate-limited and when they were replayed.