Sage X3 and Deel integration

What moves between them

The main flow runs from Deel into Sage X3. After each payroll cycle, ml-connector reads Deel's payroll invoices and employee cost data through webhooks or polling, maps them to Sage X3 GL accounts and cost allocation dimensions, and posts labor cost journals into X3's general ledger. Employee records flow one direction so X3 headcount reflects Deel hires, terminations, and contract updates. GL postings are never written back to Deel.

How ml-connector handles it

ml-connector stores both credential sets encrypted and handles Sage X3's short 5-minute token expiry by requesting new bearer tokens on a refresh schedule. For REST api1 customers, it uses HTTP Basic auth with explicit server URLs per customer. For GraphQL customers, it uses OAuth2 JWT bearer tokens. On the Deel side, ml-connector accepts API tokens or OAuth2 credentials and verifies all incoming webhook signatures with HMAC-SHA256 before processing. It polls or receives webhook events for employee and payroll changes, maps Deel cost centers and employee attributes to X3's customer-specific GL account structure, and posts the labor journals on a schedule tied to your payroll calendar. Deel's idempotency key requirement is met with a UUID v4 per job, and rate limit 429 responses trigger exponential backoff retry with Retry-After header. Every record carries a full audit trail and can be replayed if a downstream GL posting fails.

A real-world example

A mid-sized services firm runs Sage X3 for finance, procurement, and project accounting across multiple offices, and uses Deel for global payroll and contractor compliance across seven countries. Before the integration, the finance team exported payroll invoices from Deel, manually allocated them to X3 cost centers by office and project, and posted the GL entries every two weeks after payroll completion. Month-end GL reconciliation required chasing variances between Deel's invoice totals and X3's posted amounts, and headcount changes in Deel did not flow to X3, creating duplicate employee records. With Sage X3 and Deel connected, payroll journals post automatically after each payroll run, allocated to the correct cost centers and projects, and employee records stay synchronized. Month-end close no longer starts with manual GL recon work, and the finance team uses the audit trail to track every payroll posting back to Deel source data.

What you can do

• •Post Deel payroll invoices and employee cost data into Sage X3's general ledger after every payroll cycle, allocated to the correct cost centers and projects.
• •Keep Sage X3 employee records aligned with Deel hires, terminations, and contract updates.
• •Map Deel employees and cost centers to Sage X3's customer-specific GL account dimensions and cost allocation structure.
• •Authenticate Sage X3 with OAuth2 JWT (GraphQL) or HTTP Basic (REST api1), handling 5-minute token expiry, and Deel with API tokens or OAuth2, verifying webhook signatures.
• •Receive Deel payroll and employee events via webhook with signature verification, with polling fallback and retries on X3 GL posting failures.

Questions

Which direction does data move between Sage X3 and Deel?

The main flow is Deel into Sage X3. Payroll invoices and employee records move from Deel into X3, while cost centers and GL dimensions are aligned so payroll allocations land on valid accounts. Sage X3 general ledger entries are read-only in this integration, so ml-connector does not write financial data back to Deel.

How does the integration handle Sage X3's 5-minute token expiry and per-customer server URLs?

ml-connector tracks X3 token expiry and requests new bearer tokens on a refresh schedule before expiry occurs. For REST api1 customers, it stores each customer's specific server URL and port per their X3 deployment. For GraphQL customers, it uses the OAuth2 JWT flow. Both approaches keep the token fresh and maintain per-customer routing without a central X3 registry.

What does ml-connector do when Deel webhooks are unavailable or rate limits are hit?

ml-connector verifies all Deel webhook signatures with HMAC-SHA256 before processing events. If webhooks are not available, it falls back to polling payroll and employee data. When Deel returns HTTP 429 rate limit responses, ml-connector backs off with exponential retry using the Retry-After header, ensuring no payroll records are skipped.