Oracle NetSuite and Amazon Seller Central integration

What moves between them

The main flow runs from Amazon Seller Central into Oracle NetSuite. ml-connector reads orders and the settlement reports that pay them out, then posts sales invoices and settlement journals into NetSuite, with Amazon fees, refunds, and reimbursements split across the matching NetSuite GL accounts and dimensions. Item and SKU references are aligned so each order line resolves to a real NetSuite item. Inventory can flow the other direction, pushing NetSuite stock levels to Amazon listings. The general ledger stays in NetSuite, since Amazon has no GL resource, so ml-connector never writes ledger accounts back to Amazon.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Amazon side it exchanges the Login with Amazon refresh token for a one-hour access token, caches it, and refreshes before expiry, and it sends the marketplace ID and the correct regional base URL on every call. On the NetSuite side it signs a JWT with the customer private key to obtain a 60-minute M2M token against the account-specific URL, since NetSuite publishes no shared host, and re-runs the flow when a token expires. Items and customers are mapped first, so every order line references a NetSuite item that already exists. Because Amazon push events arrive only through EventBridge or SQS rather than plain HTTP, the default is to poll orders, financial events, and settlement reports on a schedule, following NextToken until it is absent, and waiting for a settlement to close before booking its journal. Settlement reports are pulled with the async create-report, poll-status, download workflow. Amazon has no universal idempotency header, so ml-connector dedupes on the AmazonOrderId and a BullMQ jobId, and posts to NetSuite with externalId upsert so a re-read order is never booked twice. Both sides return HTTP 429 with Retry-After, so it backs off with jitter, and accessing buyer address or phone requires a Restricted Data Token from the Amazon Tokens API. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods brand with roughly 150 employees runs Oracle NetSuite for finance, inventory, and accounting, and sells on Amazon through a Seller Central account fulfilled by FBA. Before the integration, an accountant downloaded the Amazon settlement report every two weeks and keyed the gross sales, FBA fees, and refunds into NetSuite by hand, then spent month-end close chasing the difference between the Amazon deposit and the orders it covered. With Oracle NetSuite and Amazon Seller Central connected, each order posts as a sales invoice against the right item, and every settlement posts as a journal with fees and refunds split to the correct GL accounts. The re-keying is gone and close starts from numbers that already tie out to the bank.

What you can do

• •Post Amazon Seller Central orders into Oracle NetSuite as sales invoices against the right customer and item.
• •Post Amazon settlement reports into NetSuite as journals, splitting fees, refunds, and reimbursements to the correct GL accounts.
• •Map Amazon ASINs and seller SKUs to NetSuite item records so every order line lands on a real item.
• •Push NetSuite inventory levels back to Amazon listings to keep available quantity in step.
• •Authenticate Amazon with Login with Amazon OAuth2 and NetSuite with its certificate-signed JWT, dedup on AmazonOrderId and externalId, with retries and a full audit trail.

Questions

Which direction does data move between Oracle NetSuite and Amazon Seller Central?

The main flow is Amazon Seller Central into Oracle NetSuite. Orders become sales invoices and settlement reports become reconciled journals, while item and SKU references are aligned so order lines resolve to real NetSuite items. Inventory can flow the other way to update Amazon listings, but the general ledger stays in NetSuite because Amazon has no GL resource, so ml-connector never writes ledger accounts back to Amazon.

Does Amazon push orders, or does ml-connector poll for them?

Polling is the default. Amazon Seller Central delivers push events only through AWS EventBridge or SQS, not plain HTTP webhooks, so ml-connector reads orders, financial events, and settlement reports on a schedule, following NextToken until it is absent. Settlement is async, so it waits for a settlement to close before booking its journal, since the settlement report is the authoritative disbursement record.

How does the integration handle the two different auth models?

ml-connector stores both credential sets encrypted. For Amazon it exchanges the Login with Amazon refresh token for a one-hour access token and refreshes before expiry, sending the marketplace ID and regional base URL on each call. For NetSuite it signs a JWT with the customer private key to get a 60-minute token against the account-specific URL, since NetSuite has no shared host and no client secret.