Acumatica and Amazon Seller Central integration

What moves between them

The primary flow runs from Amazon Seller Central into Acumatica. ml-connector reads Amazon orders and turns them into Acumatica SalesInvoice records against the right customer, and reads settlement financial events so Amazon fees, refunds, and net payouts post as journal transactions on the correct GL accounts. Listing and pricing data flows the other direction: Acumatica StockItem prices and available quantities are pushed to the matching Amazon listings so the storefront reflects ERP stock. Reference data such as SKU to inventory ID and marketplace to GL account is aligned so every line lands on a valid Acumatica dimension. Cadence follows your settlement and reporting calendar rather than a real-time push.

How ml-connector handles it

ml-connector stores both credential sets encrypted and runs two auth bridges at once: it exchanges the Amazon refresh token for a fresh access token before each batch and caches it for its one-hour life, and it holds an Acumatica OAuth session against the customer's version-locked instance URL. On the Amazon side it follows NextToken until the cursor is absent and passes the marketplace ID on every call; on the Acumatica side it pages with $top and $skip, wraps every field value in a value object, and filters on LastModifiedDateTime for incremental reads. Because Amazon financial settlement is asynchronous, it treats the Reports API settlement report as the authoritative payout source and reconciles event-level Finances data against it. SKU to inventory ID and marketplace to GL account maps are applied first so journals and invoices reference accounts that already exist. Both APIs return HTTP 429 under load, so it backs off with jitter, and it tracks the Acumatica endpoint version so an ERP upgrade does not silently break the path.

A real-world example

A growing consumer-goods seller, roughly fifty staff, runs Acumatica Cloud ERP for inventory and finance and sells across Amazon US and UK through Seller Central. Before the integration, an accountant downloaded Amazon settlement reports every two weeks and hand-keyed the gross sales, FBA fees, refunds, and net payout into the general ledger, then spent days at close reconciling Amazon deposits to the bank. With Acumatica and Amazon Seller Central connected, each marketplace order becomes a sales invoice and each settlement posts its fees and payout as a journal automatically, split by marketplace. The bank deposit ties out to the ledger on its own, and the manual re-keying step is gone.

What you can do

• •Turn Amazon Seller Central orders into Acumatica SalesInvoice records against the correct customer and SKU.
• •Post Amazon settlement fees, refunds, and net payouts into Acumatica as GL journal transactions.
• •Push Acumatica StockItem prices and available quantities out to the matching Amazon listings.
• •Bridge the Login with Amazon refresh token and Acumatica OAuth session, with NextToken and $top or $skip paging.
• •Reconcile against the asynchronous Amazon settlement report, with 429 backoff and a full audit trail per record.

Questions

Which direction does data move between Acumatica and Amazon Seller Central?

The main flow is Amazon into Acumatica. Orders become Acumatica sales invoices and Amazon settlement events post as fee and payout journals. Listing prices and stock flow the other way, from Acumatica StockItem records out to Amazon listings, so the storefront reflects ERP inventory.

Does the integration use Amazon push notifications or polling?

It polls on a schedule. SP-API does not send plain HTTP webhooks; its push events arrive only through AWS EventBridge or SQS, and there is no notification type for settlement or invoice results. ml-connector reads the Orders, Finances, and Reports APIs on a cadence tied to your settlement calendar instead.

How does it handle Acumatica's version-locked URL and Amazon's hourly token?

ml-connector stores the Acumatica endpoint version in config and validates the instance path, since a mismatched version returns 404 on every call. On the Amazon side it exchanges the long-lived refresh token for a one-hour access token and refreshes proactively, so calls do not fail mid-batch on an expired token.