Oracle NetSuite and Adobe Commerce integration

What moves between them

The main flow runs from Adobe Commerce into Oracle NetSuite. New storefront orders become NetSuite sales orders, captured Commerce invoices become NetSuite AR invoices against the right customer, and new storefront buyers are created as NetSuite customers. In the other direction, NetSuite item and inventory data is written out to Adobe Commerce products so prices and stock on hand stay current on the storefront. Order and invoice creation is triggered by Adobe Commerce webhooks as they fire, and a scheduled poll backfills anything a webhook missed, while item and stock updates run on a schedule you control.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the NetSuite side it signs a JWT with the stored private key, exchanges it for an OAuth 2.0 token at the account-specific token endpoint, and re-runs that exchange when the 60-minute token expires, since this flow has no refresh token. On the Adobe Commerce side it signs each PaaS request with the OAuth 1.0a credentials or carries the IMS bearer token, and it verifies the HMAC-SHA256 signature on every inbound webhook before acting on it. Each Commerce order is matched by its increment_id and written to NetSuite with an externalId so the ERP upserts rather than duplicates, which matters because Commerce can deliver the same webhook more than once. For OneWorld accounts the subsidiary is mapped at connection time, because NetSuite rejects transactions without it, and storefront SKUs are matched to NetSuite items so each order line lands on a real item. NetSuite returns HTTP 429 when its concurrency or frequency cap is hit, so ml-connector backs off with jitter and retries. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized direct-to-consumer brand sells through an Adobe Commerce storefront and runs Oracle NetSuite for finance and inventory across one warehouse. Before the integration, a clerk exported the day's orders from Adobe Commerce and keyed the sales orders and invoices into NetSuite by hand, which meant revenue lagged a day, stock counts drifted between the two systems, and oversold items had to be cancelled after the fact. With Oracle NetSuite and Adobe Commerce connected, each order flows into NetSuite as it is placed, invoices post against the right customer, and stock on hand from NetSuite is written back to the catalog so the storefront stops selling what is not there. The manual export-and-key step is gone and the books reflect sales the same day.

What you can do

• •Create Oracle NetSuite sales orders and AR invoices from Adobe Commerce orders and captured invoices as they are placed.
• •Create new storefront buyers as Oracle NetSuite customers and match repeat buyers to existing records.
• •Write Oracle NetSuite item prices and inventory levels back to Adobe Commerce products so the catalog stays current.
• •Bridge NetSuite certificate-based OAuth 2.0 with Adobe Commerce OAuth 1.0a or IMS tokens, and verify the Commerce HMAC webhook signature.
• •Match each Commerce order by increment_id and upsert into NetSuite by externalId, with retries and a full audit trail on every record.

Questions

Which direction does data move between Oracle NetSuite and Adobe Commerce?

The main flow is Adobe Commerce into Oracle NetSuite. Orders, captured invoices, and new customers move from the storefront into the ERP as sales orders, AR invoices, and customer records. In the other direction, NetSuite item and stock data is written back to Adobe Commerce products so prices and inventory on the storefront stay current.

How does the integration avoid creating an order in NetSuite twice?

Adobe Commerce webhooks are synchronous and can be delivered more than once, and Commerce REST has no idempotency key header. ml-connector matches each order by its increment_id and writes it to NetSuite with an externalId, so NetSuite upserts on a value that already exists rather than creating a duplicate. BullMQ job dedup on the connector side is the additional guard.

Does the connector handle the certificate-based NetSuite login and the Commerce webhook signature?

Yes. NetSuite OAuth 2.0 Client Credentials is certificate-based, so ml-connector signs a JWT with the stored private key to obtain a 60-minute token and re-runs that exchange when it expires. On the Adobe Commerce side it verifies the HMAC-SHA256 signature in the x-adobe-commerce-webhook-signature header on every inbound webhook before processing it.