Sage X3 and Rippling integration

What moves between them

The main data flow is from Rippling into Sage X3. Accounting dimensions (departments, legal entities, cost centers) and compensation structure from Rippling are synced into Sage X3 so that GL entries reference valid accounts. Sage X3 supplier and GL account master data is polled periodically to validate that Rippling postings route to existing GL dimensions. Employee records from Rippling flow on a schedule you define, aligned with your payroll calendar, and map to Sage X3 cost centers and departments. GL entries are read-only in Rippling, so ml-connector does not write financial data back into payroll.

How ml-connector handles it

ml-connector stores both credential sets encrypted and uses Rippling's OAuth2 refresh token to keep the bearer token current; if your integration uses an API key instead, ml-connector securely stores and presents that on every request. On the Sage X3 side, ml-connector accepts the full customer-specific server URL, port, and X3 folder name, since Sage X3 publishes no shared base address. Because Sage X3 does not support webhooks, ml-connector polls GL accounts, GL entries, and supplier records on a schedule tied to your accounting and payroll calendar. Rippling accounting dimensions (departments, legal entities) are read first, then mapped to Sage X3 GL accounts and cost centers so every payroll-generated GL entry references a valid account. When Rippling webhooks are available (App Shop integration), ml-connector receives employee lifecycle events in real time and syncs accounting dimension changes immediately; if you use direct API-key authentication, ml-connector polls the employees and company activity endpoints instead. Sage X3 access tokens expire in 5 minutes, so ml-connector refreshes on every request cycle. Every record carries a full audit trail and can be replayed if a downstream write fails.

A real-world example

A mid-market services company runs Sage X3 for project accounting, procurement, and general ledger, and uses Rippling for payroll, benefits, and HR across five project locations. Before the integration, the finance team manually reviewed payroll GL postings each month and adjusted cost center allocations by hand if Rippling's department structure drifted from Sage X3's cost centers. This required spreadsheet reconciliation and created month-end close delays. With Sage X3 and Rippling connected, Rippling department and cost center changes flow into Sage X3 automatically, every payroll GL posting lands on the correct project code, and the finance team's allocation step is eliminated. Month-end close now starts with labor costs already allocated to the right projects.

What you can do

• •Sync Rippling departments, legal entities, and accounting dimensions into Sage X3 so payroll GL postings route to valid cost centers.
• •Poll Sage X3 GL accounts and supplier records on a schedule you control, with delta detection using updatedDate and modifiedDateTime.
• •Authenticate Rippling via OAuth2 with automatic refresh token handling, or via direct API key.
• •Bridge Sage X3's customer-specific server URLs, ports, and folder names without a shared tenant registry.
• •Capture every record sync in the audit trail and replay failed GL postings without re-keying.

Questions

Which direction does data move between Sage X3 and Rippling?

The main flow is Rippling into Sage X3. Accounting dimensions, departments, and legal entities from Rippling sync into Sage X3 so payroll GL postings land on valid cost centers. Sage X3 supplier and GL account master data is polled to validate that Rippling postings reference existing accounts. GL entries are read-only in Rippling, so ml-connector does not write financial data back to payroll.

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

Sage X3 does not support webhooks, so ml-connector polls GL accounts, GL entries, and supplier records on a schedule you define, using updatedDate and modifiedDateTime fields to detect changes. Because Sage X3 publishes no shared base address or tenant registry, ml-connector accepts the full customer-specific server URL, port, and X3 folder name for each deployment and validates entity paths against that instance.

Does the integration require Rippling App Shop registration or can it use an API key?

ml-connector supports both. If your integration is registered in the Rippling App Shop, ml-connector receives employee lifecycle events via webhook and syncs dimension changes in real time. If you use direct API-key authentication, ml-connector polls the employees and company activity endpoints instead. Either way, OAuth2 refresh tokens or API keys are stored encrypted.