Oracle E-Business Suite and ShipStation integration

What moves between them

The main flow is from ShipStation into Oracle EBS. ml-connector polls ShipStation for new and modified shipments on a schedule you define, extracts the shipment cost and carrier information, and creates AP invoices in Oracle EBS through the ISG. Each invoice is created via a REST POST to AP_INVOICES_INTERFACE, mapped to the vendor (carrier) and cost center from the ShipStation order metadata, then a concurrent program imports the invoice from the interface table to the base AP tables for approval and payment. Shipment line items map to GL accounts configured per carrier or per order type. The flow is unidirectional: cost data moves from ShipStation to Oracle EBS, not the reverse. Because ShipStation ORDER_NOTIFY fires only on new orders, order updates and fulfillment status changes require polling GET /orders with modifyDate filter to catch modifications not broadcast by webhooks.

How ml-connector handles it

ml-connector stores ShipStation API keys and Oracle EBS ISG credentials (username, password, and instance URL) encrypted. It refreshes ShipStation API key quotas by checking rate limit headers (X-Rate-Limit-Remaining, X-Rate-Limit-Reset) on each call and backs off before hitting the per-minute ceiling. On the Oracle EBS side, it obtains a session token via Basic Auth, includes the required context headers (ctx_orgid, ctx_respapplication, ctx_responsibility) on every request, and refreshes the token when a call returns 401 before the session timeout window expires. ShipStation webhook payloads are resource pointers only, so ml-connector still makes authenticated GET calls to fetch the full order and shipment records within the tight time window before webhook state becomes stale. Shipment costs are mapped to AP invoice lines via a configuration table: each carrier or shipment type maps to a GL account and cost center already set up in Oracle EBS. Cost center defaults are applied during the mapping, so every line references a valid GL_CODE_COMBINATIONS row. Because Oracle EBS API writes to interface tables are asynchronous (the concurrent program import runs separately and may take minutes to hours), ml-connector uses jobId deduplication to avoid re-inserting the same shipment cost if the job retries. Every record carries shipment source (ShipStation order key + tracking number) and Oracle reference (GL batch, invoice number, line ID) for tracing and replay.

A real-world example

A mid-sized e-commerce operation ships orders from multiple warehouses via various carriers through ShipStation, and runs Oracle EBS for finance and procurement. Before the integration, the shipping team reviewed packed shipments and carrier invoices in ShipStation, and the finance team received monthly carrier invoices via email, then manually entered the costs into Oracle EBS as AP invoices and allocated them to the correct cost centers by warehouse and carrier. This manual process delayed AP aging visibility and created month-end reconciliation pain as the finance team matched paper invoices to EBS records. With ShipStation and Oracle EBS connected, each shipment cost flows into Oracle EBS automatically as a validated AP invoice, allocated to the warehouse and carrier cost center, so the AP aging shows accurate payables and the finance team starts close with carrier liabilities already quantified.

What you can do

• •Poll ShipStation for new and modified shipments and create corresponding AP invoices in Oracle EBS with costs allocated to the correct carriers and cost centers.
• •Map ShipStation carriers and shipment types to Oracle EBS GL accounts and cost centers via a configuration table, ensuring every line hits a valid GL combination.
• •Authenticate ShipStation via API Key and Oracle EBS via ISG session token, refreshing both when they expire or return 401.
• •Handle ShipStation webhook payloads as resource pointers by fetching the full order and shipment data via authenticated GET calls, and detect order updates via polling since ORDER_NOTIFY fires only on new orders.
• •Track every shipment and AP invoice record with shipment source (ShipStation order key and tracking) and Oracle reference (GL batch, invoice number, line ID) for end-to-end audit and replay on failure.

Questions

How does the integration handle Oracle EBS context headers and session tokens?

ml-connector obtains a session token via HTTP Basic Auth against the ISG login endpoint, which returns an accessToken in XML. It includes the required context headers (ctx_orgid, ctx_respapplication, ctx_responsibility, ctx_securitygroup, ctx_nlslanguage) on every request to route to the correct operating unit and GL book. Because tokens expire within 30 to 60 minutes, ml-connector detects a 401 response and refreshes the token before retrying, ensuring continuity across poll cycles.

Does the integration use ShipStation webhooks or polling?

ShipStation webhooks (ORDER_NOTIFY, SHIP_NOTIFY) are resource pointers only, so ml-connector still makes authenticated GET calls to fetch the full shipment data. Because ORDER_NOTIFY fires only on new orders, ml-connector also polls GET /orders with a modifyDate filter to catch order updates and status changes. This hybrid approach ensures no shipments are missed and all cost data is fresh before creating the AP invoice.

How are shipment costs mapped to Oracle EBS GL accounts and cost centers?

ml-connector uses a configuration table that maps each ShipStation carrier or shipment type to a GL account and cost center already set up in Oracle EBS. When creating the AP invoice, each line is populated with the mapped GL_CODE_COMBINATIONS ID and cost center, ensuring every invoice line hits a valid combination. If a mapping is missing, the job fails early with a clear error, preventing orphaned interface records.