Microsoft Dynamics NAV and SPS Commerce integration

What moves between them

Inbound purchase orders flow from SPS Commerce into Microsoft Dynamics NAV. ml-connector polls SPS at configurable intervals (typically 5-15 minutes) for new purchase orders from retail trading partners. Each order is mapped into NAV as a purchase order or sales order, using the vendor name and item codes stored in NAV to populate the document. Outbound acknowledgments, invoices, and advance ship notices flow from NAV back to SPS Commerce on a push cadence, wrapping each document in the RSX JSON envelope format that SPS requires. Reference data such as vendors, items, and warehouse locations are pulled from NAV to enrich the outbound documents.

How ml-connector handles it

ml-connector stores both OAuth credential sets encrypted. On the NAV side, it uses the tenant-specific OData endpoint (online or on-premises) and refreshes the Entra ID token when calls return 401. On the SPS side, it obtains a JWT bearer token from https://api.spscommerce.net/authorization/v1/token and includes it in the Authorization header on every /fulfillment/v1/ call. Inbound documents are polled from SPS on a schedule and validated against NAV's vendor and item master before mapping into purchase orders. The RSX JSON envelope format wrapping is applied to all outbound documents so SPS can translate them into X12 or EDIFACT for downstream retail partners. When SPS returns HTTP 429 rate-limit responses, ml-connector backs off exponentially with jitter and retries. Deduplication is enforced via document-level identifiers (purchaseOrderNumber, invoiceNumber) so if a document is re-queued from NAV, it does not create a duplicate in SPS. Every record carries an audit trail and can be replayed if a network call fails or a mapping error occurs.

A real-world example

A mid-sized consumer goods supplier runs Microsoft Dynamics NAV on-premises to manage purchasing, inventory, and order fulfillment. The company supplies four major retail chains (Walmart, Target, Costco, Amazon) through SPS Commerce, which acts as the EDI intermediary. Before integration, purchase orders arrived as EDI files that had to be manually parsed and re-entered into NAV, and outbound acknowledgments and shipment confirmations were exported from NAV, wrapped in EDI format, and uploaded to SPS via SFTP. This manual process created delays, duplicate orders, and discrepancies between NAV inventory and retail partner records. With the integration, retail orders flow directly into NAV as purchase orders with correct vendor and SKU mappings, acknowledgments and advance ship notices push back to SPS in real time, and the audit trail shows exactly when each order moved between systems. The supply chain team now spends hours per week on operational work instead of EDI file management.

What you can do

• •Poll SPS Commerce for incoming purchase orders from retail trading partners and map them into Microsoft Dynamics NAV with correct vendor and item dimensions.
• •Push purchase order acknowledgments, invoices, and advance ship notices from NAV back to SPS Commerce in RSX JSON format for translation into X12/EDIFACT.
• •Refresh OAuth 2.0 tokens on both sides and handle token expiry gracefully so outages do not interrupt the sync.
• •Deduplicate inbound orders and outbound documents using document-level identifiers, so re-queued records do not create duplicates.
• •Maintain a full audit trail of every order and confirmation, with replay capability if a network call fails or a mapping error occurs.

Questions

How does the integration handle the difference between EDI standards (X12, EDIFACT) and the NAV REST API?

SPS Commerce abstracts the EDI complexity. ml-connector polls SPS in REST/JSON format, maps purchase orders into NAV OData, and wraps outbound documents (invoices, ASNs) in RSX 7.7.7 JSON envelope format so SPS can translate them back into X12 or EDIFACT for your retail partners. The vendor and item mappings live in NAV; ml-connector looks up the NAV master to enrich the SPS documents.

Can the integration handle both on-premises NAV and Business Central online?

Yes. The integration accepts the OData endpoint URL as a parameter, so it works with on-premises NAV (https://{server}:{port}/{serverInstance}/api/v2.0/) and Business Central online (https://api.businesscentral.dynamics.com/v2.0/{tenantId}/api/v2.0/). OAuth 2.0 via Microsoft Entra ID is required for online and recommended for on-premises. On-premises requires the NAV Server Administrator to enable OData and open firewall port 7048.

How does the integration cope with SPS rate limits and retail onboarding timelines?

SPS rate limits are not publicly documented, so ml-connector implements exponential backoff with jitter on HTTP 429 responses and retries the call. Onboarding a new retail partner through SPS takes 4-8 weeks of testing and certification; once provisioned, the trading partner ID is provided by SPS and configured in ml-connector. The vendor master in NAV must include the retail partner name so purchase orders can be matched correctly.