Oracle JD Edwards and Amazon Seller Central integration

What moves between them

The flow runs from Amazon Seller Central into Oracle JD Edwards. ml-connector reads Amazon orders, Finances API financial events, and the settlement report, then posts the resulting journals into the JDE general ledger through an orchestration: marketplace sales revenue, referral and FBA fees, refunds, chargebacks, and SAFE-T reimbursements, each mapped to the matching JDE account and cost center. Item and listing master data can flow the same direction so JDE item records match the ASINs and SKUs you sell. Amazon is treated as a read-only accounting source, so ml-connector never writes financial entries or order changes back to Seller Central. The cadence is tied to your settlement and reconciliation schedule, with daily order polling for near real-time sales visibility.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Amazon side it exchanges the LWA refresh token for an access token, caches it for its one-hour life, and refreshes before expiry; it passes marketplace and region on each call and runs separate calls per region for multi-region sellers. On the JDE side it accepts the full AIS Server URL per customer, since JDE has no shared hostname, authenticates for a session token, and re-authenticates automatically on HTTP 444 invalid token after an AIS Server restart. Because JDE has no outbound webhooks and Amazon delivers events only through EventBridge or SQS, ml-connector polls Orders and Finances and waits for the settlement report, which is the authoritative disbursement record, rather than relying on a push. Settlement charge and fee types are mapped to JDE accounts and cost centers first, so every journal line references an account that already exists. SP-API throttling returns HTTP 429 per operation, so ml-connector backs off with jitter and follows NextToken paging until it is absent; JDE writes have no idempotency header, so it uses a stored job id per settlement to avoid posting a settlement twice. 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 about 150 employees runs Oracle JD Edwards EnterpriseOne for finance and distribution and sells through Amazon Seller Central using FBA across the US and Canada. Before the integration, the accounting team downloaded settlement reports from Seller Central every two weeks and re-keyed the sales totals, referral fees, FBA fees, and refunds into JD Edwards by hand, then spent the first days of close untangling which deposit covered which fees. With the two systems connected, each settlement posts into the JDE general ledger automatically, split into sales, fees, and refunds against the right accounts and cost centers, and daily order polling gives finance current marketplace sales. Month-end close starts with the Amazon accounts already reconciled and the manual entry gone.

What you can do

• •Post Amazon Seller Central settlement journals into the Oracle JD Edwards general ledger, split into sales, fees, refunds, and reimbursements against the correct accounts and cost centers.
• •Poll Amazon orders daily for near real-time marketplace sales visibility in JD Edwards.
• •Map Amazon settlement charge and fee types to JDE accounts and cost centers so every journal line lands on a valid account.
• •Bridge Amazon Login with Amazon OAuth2 refresh tokens and the JD Edwards session token, refreshing each automatically before it expires.
• •Use a stored job id per settlement so a settlement is never posted twice, with retries and a full audit trail on every record.

Questions

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

The flow runs from Amazon Seller Central into Oracle JD Edwards. Settlement financial events, orders, and item data move from Amazon into JDE, where sales and fee journals are posted through an orchestration. Amazon is treated as a read-only accounting source, so ml-connector does not write financial entries or order changes back to Seller Central.

How does the integration handle the lack of webhooks on both sides?

JD Edwards has no native outbound webhooks, and Amazon delivers events only through AWS EventBridge or SQS with no settlement notification type. ml-connector polls the Amazon Orders and Finances APIs and waits for the settlement report, which is the authoritative disbursement record. JDE changes are read by polling the data service on the UPMJ updated date.

How are writes made into JD Edwards, since direct table writes are not allowed?

The JDE data service is read-only, so all writes go through named orchestrations the customer imports into Orchestrator Studio, such as JDE_ORCH_04_Add_Supplier_Invoice for AP entries or a journal entry orchestration for GL postings. ml-connector accepts the orchestration name as configuration and posts each Amazon settlement journal through it, using a stored job id so the same settlement is not posted twice.