Xero and Adobe Commerce integration

What moves between them

The main flow runs from Adobe Commerce into Xero. Completed orders and Commerce invoices are created as Xero accounts receivable invoices, and Commerce credit memos become Xero credit notes, each mapped to the right Xero account codes and tax types. Storefront customers flow the same direction and are matched to or created as Xero contacts with the customer role. Product records are aligned by SKU between Commerce products and Xero items so invoice lines reference known stock codes. Payment capture amounts read from Commerce orders and invoices can be recorded against the Xero invoice. Cadence is event driven where Commerce webhooks fire, backed by a scheduled poll of both systems for anything a webhook misses.

How ml-connector handles it

ml-connector stores both credential sets encrypted. It signs each Adobe Commerce PaaS call with the four OAuth 1.0a values, or requests an IMS token on the Cloud Service and refreshes it before the roughly 24 hour expiry, while on the Xero side it sends the bearer token plus the Xero-tenant-id and refreshes the 30 minute access token using the 60 day refresh token. Because Xero webhook payloads carry only IDs, every Xero event triggers a follow up GET, and Xero items and chart of accounts are picked up by scheduled polling since they have no webhook. Adobe Commerce account codes and tax types are mapped to Xero accounts and tax rates first, so each invoice line lands on a valid Xero code. Xero allows 60 calls per minute and 5,000 per day per organization and returns 429 with Retry-After, so reads use If-Modified-Since and paging to stay within budget. Because neither system has an idempotency header, the connector anchors on increment_id on the Commerce side and the Xero record GUID, and dedupes work by jobId so a retried event does not create a duplicate invoice.

A real-world example

A direct to consumer brand with about 60 staff sells through an Adobe Commerce storefront and keeps its books in Xero. Before the integration, an accounts clerk exported the day's orders and refunds from Commerce and entered each one into Xero by hand, which lagged a day or more and produced mismatches between storefront totals and the ledger at month end. With Xero and Adobe Commerce connected, each completed order posts as a Xero invoice and each refund as a credit note within minutes, contacts are created the first time a buyer appears, and the revenue accounts reconcile to the storefront without the manual export step.

What you can do

• •Create Xero accounts receivable invoices from completed Adobe Commerce orders and Commerce invoices.
• •Post Adobe Commerce credit memos into Xero as credit notes mapped to the right accounts.
• •Match Adobe Commerce storefront customers to Xero contacts and keep product records aligned by SKU.
• •Bridge Adobe Commerce OAuth 1.0a or IMS OAuth 2.0 with the Xero OAuth 2.0 tenant token.
• •Combine Commerce webhook events with scheduled Xero polling, with retries and a full audit trail on every record.

Questions

Which direction does data move between Xero and Adobe Commerce?

The main flow is Adobe Commerce into Xero. Orders and Commerce invoices become Xero accounts receivable invoices, credit memos become Xero credit notes, and storefront customers are matched to Xero contacts. Product records are aligned by SKU, and general ledger coding is applied on the Xero side because Adobe Commerce has no GL accounts resource.

How does the integration handle the different logins on each side?

ml-connector stores both credential sets encrypted and signs each Adobe Commerce PaaS request with OAuth 1.0a, or requests and refreshes an IMS OAuth 2.0 token on the Cloud Service. On the Xero side it sends a bearer token with the Xero-tenant-id header and refreshes the 30 minute access token using the 60 day refresh token, so neither connection drops mid sync.

Does the integration rely on webhooks or polling?

It uses both. Adobe Commerce can fire synchronous webhooks on storefront events, and the connector also polls Xero on a schedule. Xero webhook payloads carry only record IDs, so each Xero event triggers a follow up GET, and Xero items and chart of accounts changes are caught by polling because Xero does not send webhooks for them.