Oracle JD Edwards and ShipBob integration

What moves between them

The main flow runs from JD Edwards into ShipBob. Sales orders are polled from JD Edwards on your fulfillment schedule and pushed to ShipBob, along with item master data and on-hand quantities. ShipBob acknowledges order receipt via webhook, and when fulfillment begins, sends order.shipped and order.shipment.tracking.updated events. ml-connector captures these events and posts shipment records and COGS journals into JD Edwards' GL. Return orders flow the same direction: ShipBob detects a return.created event, ml-connector logs it in JD Edwards as a reverse shipment, and the return completion updates inventory and reverses the original COGS posting. Reference data such as item dimensions and weight is refreshed bidirectionally so ShipBob's fulfillment plans use current JD Edwards item specifications.

How ml-connector handles it

ml-connector polls JD Edwards on a customer-defined cadence (typically daily or per-shift) by acquiring a fresh session token, querying F4201 and F4211 for open orders with updated date since the last poll, and mapping order line items to ShipBob's POST /orders endpoint. It stores both JD Edwards session credentials and ShipBob OAuth credentials encrypted. On the ShipBob side, ml-connector receives webhooks at a registered HTTPS endpoint, validates the HMAC-SHA256 signature using the webhook secret and the v1 envelope, and parses the event payload. When order.shipped fires, ml-connector reads the full shipment from ShipBob's GET /shipments/{id} endpoint, fetches the corresponding order and item details from JD Edwards, calculates COGS using JD Edwards' item costing method (standard or weighted average), and posts a GL journal entry (via F0911Z1) to deferred revenue and COGS accounts. JD Edwards session tokens expire every 30 to 60 minutes, triggering a 444 response on the next request; ml-connector detects this and re-authenticates without surfacing the error. ShipBob OAuth tokens expire hourly and are refreshed preemptively. If an order exists in ShipBob but not in JD Edwards, the shipment is logged to the audit trail for manual review rather than creating a GL entry. Every record carries full traceability: order number, shipment ID, posting date, journal entry number, and the source timestamp from ShipBob's event.

A real-world example

A mid-market consumer goods company manufactures and distributes products across North America. Their sales order entry happens in JD Edwards running on-premises; inventory staging happens at two ShipBob fulfillment centers. Before the integration, the warehouse team emailed JD Edwards orders to ShipBob daily, and finance received shipment reports from ShipBob separately to manually post GL entries at month-end close. This created a three-day lag between order shipment and GL posting, leaving the revenue cycle and aging reports out of sync. Returns from customers were logged in ShipBob but lost in the JD Edwards inventory system, creating ghost inventory until the physical recount. With Oracle JD Edwards and ShipBob connected, each day's orders push automatically to the fulfillment centers. As soon as ShipBob ships, the event posts COGS and revenue into JD Edwards in real time. Returns reverse the original posting, and inventory stays accurate. Month-end close now starts with shipments and revenue already posted.

What you can do

• •Push sales orders and item master data from JD Edwards to ShipBob, refreshing inventory quantities on each fulfillment cycle.
• •Receive shipment tracking and delivery events from ShipBob via webhooks and post COGS and revenue GL entries into JD Edwards.
• •Map JD Edwards item costing (standard or weighted average) to ShipBob shipment line items for accurate GL posting.
• •Handle JD Edwards session token expiry and ShipBob OAuth token refresh transparently without stopping the sync.
• •Log returns from ShipBob back to JD Edwards inventory and reverse the original COGS posting on return completion.

Questions

Which direction does data move between JD Edwards and ShipBob?

The primary flow is JD Edwards to ShipBob: sales orders, items, and inventory quantities are pushed daily. Fulfillment events flow back via ShipBob webhooks: shipments trigger COGS and revenue postings, and returns reverse those entries. Item details such as unit of measure, cost, and specifications are kept aligned so ShipBob's picking uses current JD Edwards data.

How does ml-connector handle JD Edwards on-premises AIS Server and session tokens?

ml-connector requires the customer AIS Server URL and login credentials as configuration. It polls by acquiring a fresh session token on each cycle (or reusing a valid token within its 30 to 60 minute lifetime), issuing REST queries to F-table data service endpoints with date filters, and handling 444 responses by re-authenticating. Token storage is encrypted per cell.

What happens if a ShipBob order arrives without a matching JD Edwards sales order?

ml-connector validates that an order exists in JD Edwards before posting COGS or revenue. If the order is missing, the shipment event is logged to the audit trail with full context so the operations team can investigate and resolve the mismatch manually. This prevents GL entries from being posted to non-existent orders.