Oracle JD Edwards and ShipStation integration

What moves between them

The primary flow runs from JD Edwards into ShipStation. Purchase order headers and line items are read from JD Edwards tables F4301 and F4311, mapped to ShipStation orders and purchase_orders entities, and created or updated for carrier selection and shipment scheduling. The secondary flow runs from ShipStation back into JD Edwards. Shipment tracking data, carrier details, and shipment status are polled from ShipStation on a daily or per-shipment cadence (configurable), then transformed into JD Edwards goods receipt transactions (F0413 AP Matching Document) and posted into the accounts payable ledger (F0411) for automated three-way matching. Item master records (F4102) are synchronized bidirectionally so SKU and unit-of-measure references remain consistent.

How ml-connector handles it

ml-connector stores the AIS Server URL, JD Edwards username, and password encrypted, and generates a new session token on startup and after any 444 (invalid token) response. Token lifetime is checked against the configured timeout (default 30-60 minutes) and refreshed preemptively before expiry to avoid mid-request failures. For ShipStation, the API key and secret are stored encrypted and presented on every V1 request via the Authorization header as base64-encoded Basic auth. ml-connector polls JD Edwards tables F4311 and F0411 every 4 hours (configurable) using UPMJ date filters to detect changes since the last successful poll. On ShipStation, ml-connector listens for SHIP_NOTIFY webhooks, immediately fetches the referenced shipment via authenticated GET, and then polls the V1 /orders endpoint every 6 hours for order edits not caught by webhooks. Mapping JD Edwards to ShipStation happens at the order and line-item level: F4301 headers become ShipStation order records keyed by JD Edwards POID (Purchase Order ID), and F4311 detail lines become order items. For the return flow, ShipStation shipment tracking is matched to JD Edwards PO lines by comparing PO number and item SKU, then posted into the goods receipt batch (F0911Z1) and the AP ledger. IP allowlists on the AIS Server are checked at configuration time by attempting a token request; if the allowlist is active, the connector's outbound IP must be whitelisted in customer infrastructure. All poll timestamps and match keys are logged in the audit trail, and any shipment-to-goods-receipt mapping failure halts that batch and surfaces the error so the user can manually reconcile.

A real-world example

A mid-sized distributor runs JD Edwards on premises for procurement, inventory, and finance, and uses ShipStation to manage order fulfillment and carrier selection for multiple e-commerce sales channels and wholesale customer shipments. Before the integration, purchase orders entered into JD Edwards for wholesale customers were manually re-keyed into ShipStation by the supply chain team so carriers could be selected and labels printed, and shipment tracking numbers were then emailed or manually looked up and hand-entered back into JD Edwards for goods receipt posting. This process was error-prone, delayed the posting of goods receipts by 1-3 days, and created month-end reconciliation delays when AP matching discovered mismatches between PO line items and received quantities. With JD Edwards and ShipStation connected, new purchase orders flow automatically from JD Edwards into ShipStation every 4 hours, shipments are generated as soon as carriers are selected and labels are printed in ShipStation, tracking information flows automatically back into JD Edwards for three-way AP matching, and goods receipt postings now happen the same day shipments leave the warehouse.

What you can do

• •Sync purchase order headers and line items from JD Edwards into ShipStation for carrier selection and label generation.
• •Receive shipment tracking, carrier details, and shipment status from ShipStation and post goods receipts automatically into JD Edwards accounts payable.
• •Keep item master records and unit-of-measure references synchronized between JD Edwards and ShipStation so PO lines map correctly to shipment items.
• •Refresh JD Edwards AIS Server session tokens every 30-60 minutes and handle 444 invalid-token errors without manual re-authentication.
• •Poll both systems on a configurable schedule with date-filter tracking and full audit trail on every record, supporting replay if a goods receipt fails to post.

Questions

Which direction does data move between JD Edwards and ShipStation?

The primary flow is JD Edwards to ShipStation: purchase orders and open AP line items flow from JD Edwards into ShipStation for carrier selection and shipment scheduling. The secondary flow is ShipStation to JD Edwards: shipment tracking data and carrier details flow back into JD Edwards for goods receipt and AP matching. Item master records are synchronized bidirectionally so SKU references remain consistent.

Why does ml-connector need to poll both systems instead of relying on webhooks?

JD Edwards has no native outbound webhooks for procurement data, so all purchase orders and AP transactions must be read by polling the data service tables with date filters. ShipStation provides webhooks for shipment events but not for order updates or edits, so polling is still required to detect order changes. ml-connector tracks last-polled timestamps to avoid duplicates and reprocessing the same records.

How does ml-connector handle JD Edwards AIS Server token refresh and IP allowlist requirements?

ml-connector generates a new session token at startup and again when any request returns 444 (invalid token), tracking token age and refreshing preemptively before the configured timeout (default 30-60 minutes) expires to avoid mid-request failures. It also checks IP allowlist configuration at setup time by attempting a token request; if the AIS Server has an allowlist enabled, the connector's outbound IP must be whitelisted in the customer's JD Edwards infrastructure before any polling begins.