Microsoft Dynamics 365 Business Central and ShipStation integration

What moves between them

Records move in both directions. From Microsoft Dynamics 365 Business Central into ShipStation, ml-connector pushes items as ShipStation products and keeps customer detail aligned, so the SKUs and ship-to addresses ShipStation needs to fulfill an order already exist. From ShipStation back into Business Central, each shipped order flows in as a sales order or posted sales invoice, and the shipment record carries its tracking number, carrier, and service code onto the matching document. New orders and shipments arrive through ORDER_NOTIFY and SHIP_NOTIFY webhooks, and a scheduled poll on modifyDate backfills the order edits ShipStation never sends an event for. ShipStation has no accounting objects, so ml-connector never tries to read GL data out of it.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the Business Central side it holds a Microsoft Entra ID client credentials token for the tenant and targets the company id on the configured environment name, since the environment is part of the URL, and it reads incrementally with an OData filter on lastModifiedDateTime. On the ShipStation side it sends the Base64 Basic auth header on V1 order, product, and shipment calls and the API-Key header on V2 label calls, and it converts every V1 timestamp from PST or PDT before a ship date reaches a Business Central document. Business Central items are pushed to ShipStation as products keyed on SKU so fulfillment never blocks on a missing item. Inbound, each new order and shipment arrives as an ORDER_NOTIFY or SHIP_NOTIFY webhook that carries only a resource_url, so the connector follows the pointer with an authenticated GET to fetch the full record, then writes a Business Central sales order or creates and posts a sales invoice with the Microsoft.NAV.post bound action, attaching the tracking number, carrier, and service code. Because ShipStation sends no webhook for order edits, a scheduled poll on modifyDate catches changes to open orders, and the orderKey is used as the stable external reference so the same order is never booked twice. The connector can renew the three-day Business Central subscriptions before they expire so the change feed never goes dark. ShipStation V1 returns HTTP 429 at roughly forty requests per minute and Business Central returns HTTP 429 when throttled, so the connector backs off with jitter and retries, and 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 company of about ninety staff runs Microsoft Dynamics 365 Business Central for inventory, sales, and finance, and uses ShipStation to consolidate orders from its website and two marketplaces and to print carrier labels. Before the integration, a fulfillment clerk re-typed each web order into ShipStation, then after shipping copied the tracking number and order total back into Business Central by hand, which left stock counts lagging and produced mismatched orders the finance team untangled at month-end. With the two systems connected, Business Central items and customers stay current in ShipStation, every shipped order flows back as a sales invoice with its tracking number attached, and a modifyDate poll catches later edits. The double entry is gone and the books reflect what actually shipped.

What you can do

• •Push Microsoft Dynamics 365 Business Central items to ShipStation as products keyed on SKU so fulfillment never blocks on a missing item.
• •Keep Business Central customer detail aligned with the ship-to data ShipStation needs to fulfill orders.
• •Read each shipped ShipStation order back into Business Central as a sales order or posted sales invoice.
• •Attach the ShipStation tracking number, carrier, and service code to the matching Business Central document.
• •Bridge Business Central Microsoft Entra ID login and ShipStation Basic auth, catch orders by webhook plus a modifyDate poll, and keep a full audit trail on every record.

Questions

Which direction does data move between Microsoft Dynamics 365 Business Central and ShipStation?

It moves both ways. Items and customers flow from Business Central into ShipStation so the SKUs and ship-to addresses needed for fulfillment exist there, and each shipped order flows from ShipStation back into Business Central as a sales order or posted sales invoice with its tracking number. ShipStation has no GL accounts or invoices, so ml-connector never reads accounting data out of it.

ShipStation sends no webhook for order edits, so how does the integration stay current?

ShipStation only pushes ORDER_NOTIFY and SHIP_NOTIFY webhooks for new orders and shipments, and each carries just a resource_url pointer that ml-connector follows with an authenticated GET. There is no event for an edited order, so the connector also polls Business Central and ShipStation on a schedule, filtering ShipStation by modifyDate, and uses the orderKey as the stable reference so the same order is never booked twice.

How does the integration post into Business Central given its draft-then-post invoice model?

Business Central creates a sales invoice as a draft first and only posts it with the Microsoft.NAV.post bound action. ml-connector builds the sales order or draft invoice from the ShipStation order, then calls that bound action to post it, attaching the tracking number and carrier. It also renews the three-day Business Central webhook subscriptions before they expire so the change feed never goes dark.