Zoho Books and Tradeshift integration

What moves between them

Invoices and purchase orders move from Tradeshift into Zoho Books. Tradeshift suppliers publish invoices to the network; ml-connector polls Tradeshift on a schedule, parses the UBL XML documents, and posts them to Zoho Books as bills matched by vendor contact and line item amounts. Purchase orders can flow in either direction depending on customer setup: poll from Zoho and publish to Tradeshift if the customer manages POs centrally and shares with suppliers via the network. Remittance advice and receipts from Tradeshift can also be synced if integrated with Zoho's vendor payment workflows.

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted: Zoho's refresh token and organization ID, and Tradeshift's consumer and token pairs plus tenant ID. On the Zoho side it detects the customer's region from the OAuth token response and routes all subsequent calls to the correct regional base URL, using the organization_id on every request. On the Tradeshift side it builds OAuth 1.0a signatures per RFC 5849 for each GET documents/v2/ poll, using the changedAfter parameter to avoid re-processing old documents. Incoming UBL documents are parsed to extract vendor name, invoice/PO number, line items, amounts, and currency, then mapped to matching Zoho contacts and posted as bills. Zoho rate limits are handled with exponential backoff (100 requests/minute, max 10 new access tokens per 10-minute window); Zoho access tokens are refreshed proactively at 55 minutes. Every record carries a BullMQ jobId for deduplication and a full audit trail.

A real-world example

A mid-sized distributor uses Zoho Books for accounting and is part of the Tradeshift B2B network where suppliers publish invoices electronically. Before the integration, the accounts payable team downloaded Tradeshift documents weekly, extracted invoice numbers and amounts from XML files, and keyed them into Zoho Books by hand, prone to typos and timing delays. With Zoho Books and Tradeshift connected, supplier invoices post directly into Zoho as bills, matched by vendor, on a daily schedule. The AP team sees invoices in Zoho within hours of the supplier publishing them to the network, and the manual re-entry step is eliminated.

What you can do

• •Sync invoices and purchase orders from Tradeshift to Zoho Books, parsing UBL XML documents and matching vendors by contact.
• •Route all Zoho API calls to the correct regional base URL based on customer region, ensuring multi-region deployments work correctly.
• •Handle OAuth 1.0a signing for Tradeshift and OAuth2 token refresh for Zoho Books, with encrypted credential storage and rotation.
• •Poll Tradeshift documents on a schedule with timestamp-based filtering to avoid re-processing and handle Zoho rate limits with exponential backoff.
• •Maintain a full audit trail on every record with BullMQ jobId deduplication and replay capability if a downstream sync fails.

Questions

Which direction do documents move between Zoho Books and Tradeshift?

Invoices and purchase orders move from Tradeshift into Zoho Books. Supplier invoices published to the Tradeshift network are polled, parsed from UBL XML, and posted to Zoho as bills. Purchase orders can flow from Zoho to Tradeshift if the customer publishes POs to suppliers via the network. Remittance advice and receipts from Tradeshift integrate with Zoho's vendor payment workflows.

How does ml-connector handle Zoho's regional base URLs and organization ID requirement?

Every Zoho Books customer lives in exactly one region (US, EU, India, Australia, Japan, Canada, China, or Saudi Arabia). ml-connector detects the customer's region from the OAuth token response and routes all API calls to the correct regional base URL. The organization_id is resolved after authentication and included as a query parameter on every subsequent call, so multi-region setups work transparently.

How are Zoho rate limits and OAuth token expiry handled?

Zoho Books rate limit is 100 requests/minute and 10 new access tokens per 10-minute window. ml-connector uses exponential backoff on HTTP 429 responses and proactively refreshes access tokens at 55 minutes before expiry. Tradeshift polling uses timestamp-based filtering (changedAfter) to avoid re-fetching old documents, and both systems carry full jobId deduplication to prevent duplicate posts if a retry occurs.