Oracle NetSuite and ShipBob integration

What moves between them

Inventory flows from ShipBob receiving (WRO) events into Oracle NetSuite's inventory balance when boxes arrive at the warehouse. Shipment tracking from ShipBob updates NetSuite sales orders with carrier, tracking number, and delivery status after each shipment event. NetSuite purchase orders flow into ShipBob on a schedule to trigger replenishment inbound, matched against ShipBob receiving orders. Returns from ShipBob feed back into NetSuite inventory adjustments. The cadence is event-driven for shipments and returns (within seconds of the ShipBob event) and daily-polled for purchase orders to ShipBob.

How ml-connector handles it

ml-connector stores encrypted OAuth2 credentials for both systems and exchanges expired tokens before they are needed. On the ShipBob side, it validates the HMAC-SHA256 signature on every incoming webhook using the shared secret, and appends the shipbob_channel_id header on every outbound call to write inventory or replenishment data. On the Oracle NetSuite side, it uses the certificate-based OAuth2 Client Credentials flow to obtain fresh tokens and constructs SuiteQL queries to poll for new purchase orders. ShipBob WRO (Warehouse Receiving Order) events trigger the inventory posting into NetSuite's inventory module, keyed by the product variant SKU matched against NetSuite's inventory item number. Shipment tracking events parse the carrier and tracking number from ShipBob's order.shipment.tracking.updated webhook and update the corresponding NetSuite sales order fulfillment status. Returns and billing charges from ShipBob are mapped back to NetSuite's return-merchandise authorization and accounts-payable flows. Rate limits on ShipBob return HTTP 429, and ml-connector backs off and retries exponentially. Every record is logged with a full audit trail for month-end reconciliation.

A real-world example

A mid-sized apparel retailer stocks inventory at two ShipBob fulfillment centers and runs Oracle NetSuite for purchasing, accounting, and order management. Before the integration, the warehouse team received inventory inbound into ShipBob weekly, and the finance team manually entered those counts into NetSuite every Friday to keep the inventory ledger current. Orders created in NetSuite for web sales had to be manually entered into ShipBob's purchase-order system for picking and packing. When a shipment moved in ShipBob, customers could not see the tracking in NetSuite. With the integration, ShipBob WRO events post directly to NetSuite inventory, purchase orders from NetSuite flow automatically to ShipBob, and every shipment update embeds tracking into the sales order. The finance team no longer re-enters inbound inventory, and customers can see tracking in their order history without manual SMS or email forwarding.

What you can do

• •Sync inventory inbound from ShipBob Warehouse Receiving Orders into Oracle NetSuite's inventory ledger, keyed by product SKU and variant.
• •Embed ShipBob shipment tracking (carrier, tracking number, delivery status) into NetSuite sales orders in real time.
• •Push NetSuite purchase orders to ShipBob daily to trigger replenishment inbound and warehouse receiving.
• •Map ShipBob returns and billing charges back into NetSuite for accounts payable and inventory adjustments.
• •Validate ShipBob webhook signatures with HMAC-SHA256 and refresh OAuth2 credentials before expiry on both sides.

Questions

How does the integration handle inventory SKU matching between Oracle NetSuite and ShipBob?

ml-connector matches ShipBob product variant SKUs against NetSuite inventory item numbers during every warehouse receiving event. The SKU field in ShipBob must be populated and must exist in NetSuite for the inventory posting to succeed. If a SKU is missing or mismatched, the event is logged and can be replayed once the SKU is added to NetSuite.

Which direction does data move, and what happens to NetSuite sales orders when ShipBob ships?

Inventory flows inbound from ShipBob into NetSuite. Purchase orders flow from NetSuite to ShipBob daily. When ShipBob ships an order, tracking events update the corresponding NetSuite sales order with carrier and tracking number, but the fulfillment is read-only from NetSuite's perspective. Returns and billing charges flow from ShipBob back into NetSuite for accounting.

How does ml-connector handle ShipBob's OAuth token expiry and the channel_id requirement?

ShipBob OAuth access tokens expire every 1 hour; ml-connector refreshes them before expiry using the 30-day refresh token. Every outbound write to ShipBob includes the required shipbob_channel_id header to ensure the write is authorized on behalf of your merchant channel. If a token refresh fails, the error is logged and surfaced so the token can be renewed manually.