Visma and Adobe Commerce integration

What moves between them

Customer records move from Adobe Commerce into Visma to keep the customer master file aligned with order activity. Invoice data flows both ways: Adobe Commerce invoices created from orders are sent to Visma as reference records, and Visma supplier invoices tied to purchase orders are polled and recorded in Adobe Commerce for procurement reconciliation. Both flows run on a daily schedule tied to your business cycle, with missed changes picked up on the next poll. GL posting happens in Visma only; Adobe Commerce has no GL endpoint, so ml-connector maps order amounts to Visma's accounts and dimensions.

How ml-connector handles it

ml-connector stores both credential sets encrypted and manages two separate OAuth flows: Visma's client credentials against Visma Connect (with the required ipp-company-id header on every call), and Adobe Commerce's OAuth 1.0a signature (PaaS) or OAuth 2.0 bearer token (SaaS). On the Visma side, it polls customer, invoice, and purchase order lists using lastModifiedDateTime to detect changes since the last sync, and on every update (PUT) it reads the current ETag, includes it in the request, and retries if a 409 conflict occurs due to a race. Adobe Commerce webhooks are preferred when available (version 2.4.4+) for real-time order and invoice notification, but the integration falls back to polling if webhooks are not enabled. Rate-limit handling respects Visma's 500-call-per-hour test limit and Adobe Commerce's per-minute thresholds, backing off exponentially on 429 responses. Every customer, order, and invoice record carries an audit trail and can be replayed if a downstream validation fails.

A real-world example

A mid-market Nordic retailer runs Visma.net ERP for accounting and AP/AR and hosts its online storefront on Adobe Commerce. Before the integration, the order fulfillment and accounting teams worked in parallel: e-commerce staff exported daily orders from Commerce and emailed them to accounting, who then manually entered each order as a customer invoice in Visma, creating a lag of one to three days and frequent entry errors. At the same time, supplier invoices in Visma were printed and filed without being visible to the procurement team in Commerce. With Visma and Adobe Commerce connected, each new order flows automatically into Visma as a customer invoice on the same day, mapped to the correct customer and GL account. Supplier invoices are posted back to Commerce for visibility, and the accounting team can start their close process with all invoices already recorded and reconciled.

What you can do

• •Sync customer master records from Adobe Commerce into Visma so your accounting customer list stays in step with e-commerce orders.
• •Post Adobe Commerce orders into Visma as customer invoices with GL account and dimension mapping.
• •Read Visma supplier invoices and create reference records in Adobe Commerce for procurement visibility.
• •Authenticate both systems securely: Visma via OAuth 2.0 client credentials with required ipp-company-id headers, and Adobe Commerce via OAuth 1.0a (PaaS) or OAuth 2.0 (SaaS).
• •Handle Visma ETag-based optimistic locking, polling on a daily schedule, and fallback to polling if webhooks are unavailable.

Questions

Which direction does data move between Visma and Adobe Commerce?

Customer records and order data move from Adobe Commerce into Visma so orders are recognized for accounting. Supplier invoices flow from Visma back to Adobe Commerce for procurement visibility. Both directions run on a daily schedule, so the two systems stay aligned for close and reconciliation.

Why does the integration need to poll Visma instead of using webhooks?

Visma webhooks are one-time delivery only with no automatic retry, making them unreliable for critical accounting records. ml-connector polls Visma's customer, invoice, and purchase order endpoints using the lastModifiedDateTime parameter to catch all changes reliably. On the Adobe Commerce side, webhooks are used if available (version 2.4.4+) for real-time order notification.

How does ml-connector handle Visma's ETag requirement and OAuth differences between systems?

On Visma updates, ml-connector reads the current ETag, includes it in the PUT request, and retries if a 409 conflict occurs due to a concurrent change. It manages two separate OAuth flows: Visma's client credentials with the required ipp-company-id header on every call, and Adobe Commerce's OAuth 1.0a (PaaS) or OAuth 2.0 (SaaS) bearer token, with encrypted storage of all credentials.