Sage X3 and Cleo integration

What moves between them

Purchase orders, sales invoices, and supplier data move from Sage X3 into Cleo on a configurable schedule. ml-connector reads from Sage X3 using delta detection (checking updatedDate fields since the last poll) and writes the normalized records to Cleo as EDI 850 (purchase order) and 810 (invoice) transactions. Cleo then routes these documents to the appropriate trading partners according to partner configuration. Reference data such as suppliers and customers are kept in sync to ensure EDI payloads reference valid trading partners. This is a one-way flow from ERP to integration platform.

How ml-connector handles it

ml-connector accepts the Sage X3 instance URL and port (customer-specific, not shared), authenticates using either OAuth2 (for GraphQL endpoints) or HTTP Basic Authentication (for REST api1), and automatically refreshes tokens before they expire. For Cleo, it stores the username and password encrypted, exchanges them for a short-lived OAuth2 bearer token on each request, and refreshes when needed. On the Sage X3 side, ml-connector polls on a schedule using delta detection with updatedDate and modifiedDateTime fields, so only changed records are fetched and pushed to Cleo. It maps Sage X3 purchase order, invoice, and supplier entities to Cleo EDI transactions (850 and 810), normalizing customer and supplier references to match Cleo trading partner names. Because neither Sage X3 nor Cleo offer native outbound webhooks, ml-connector uses polling on both sides, controlled by the sync schedule you define. It handles token expiry, retries on transient failures, and tracks every record transformation in an audit trail for compliance.

A real-world example

A mid-sized distributor runs Sage X3 for procurement and finance, managing several hundred trading partners for inbound raw materials and outbound finished goods. Before the integration, the supply chain team exported purchase orders from Sage X3 daily, converted them manually to EDI 850 format in a separate tool, and uploaded the files to Cleo. The same process happened for shipment notifications and invoices. With Sage X3 and Cleo connected, each new or updated purchase order in Sage X3 flows automatically to Cleo as an EDI 850 within the polling window, ready for trading partner delivery without intermediate steps. The finance team's invoices and shipment confirmations flow the same way, reducing manual work and keeping EDI documents in sync with the source of truth in Sage X3.

What you can do

• •Sync purchase orders from Sage X3 to Cleo as EDI 850 transactions on a configurable schedule.
• •Transform Sage X3 invoices into Cleo EDI 810 format and deliver them to trading partners.
• •Keep supplier and customer references aligned between Sage X3 and Cleo so EDI transactions reference valid partners.
• •Poll Sage X3 using delta detection to fetch only changed records since the last sync, reducing API load.
• •Authenticate Sage X3 with OAuth2 or HTTP Basic Auth and Cleo with OAuth2 password grant, bridging the different auth models.

Questions

Which direction does data move between Sage X3 and Cleo?

Data flows one way from Sage X3 into Cleo. Purchase orders, invoices, and supplier reference data are read from Sage X3 and written to Cleo as EDI transactions for trading partner delivery. Cleo does not write back to Sage X3.

How does ml-connector handle Sage X3's customer-specific URL and lack of webhooks?

ml-connector accepts the full Sage X3 instance URL and port per customer, since Sage X3 does not publish a shared hostname. Because neither Sage X3 nor Cleo support outbound webhooks, ml-connector polls Sage X3 on a schedule using delta detection with updatedDate fields, so only changed records are fetched and sent to Cleo.

What authentication does the integration use for each system?

Sage X3 authenticates with OAuth2 bearer tokens (for GraphQL) or HTTP Basic Authentication (for REST api1), both configured per customer instance. Cleo authenticates with OAuth2 password grant, where ml-connector exchanges the stored username and password for a bearer token and refreshes it when needed.