How does ml-connector handle the RSX JSON envelope format that SPS requires?

ml-connector receives documents wrapped in RSX 7.7.7 envelopes from SPS, extracts the inner transaction payload (purchase order, ASN, inventory advice, etc), validates it against the NetSuite schema, and writes it as a native NetSuite record. On outbound, ml-connector reads from NetSuite and wraps documents in the RSX format SPS expects before posting them back.

What happens when a trading partner ID from SPS does not match a NetSuite vendor?

ml-connector requires a manual mapping table at setup time that links each SPS trading partner ID to a NetSuite vendor and cost center. If an order arrives with an unmapped partner ID, it is logged to the audit trail and quarantined so the team can review the mapping before replay.

Does ml-connector handle SPS rate limits and certification delays for new trading partners?

Yes. SPS does not publish rate limits, so ml-connector implements exponential backoff with jitter on 429 responses. For new trading partners, SPS requires a 4 to 8 week certification phase during which documents are tested in SPS before live transmission begins, and ml-connector tracks this status so orders are not attempted before the partner is certified.

Oracle NetSuiteSPS Commerce

Oracle NetSuite and SPS Commerce integration

Oracle NetSuite runs procurement and inventory. SPS Commerce connects suppliers to retailers through EDI. Linking them lets you receive orders from trading partners through SPS and write them into NetSuite without re-keying, track advance ship notices and inventory advice through the same pipe, and keep your supplier master and cost center mapping aligned with the partner IDs SPS provisions. ml-connector handles the very different authentication models and message formats on each side.

How Oracle NetSuite works

Oracle NetSuite exposes vendors, purchase orders, invoices, inventory items, and customer records through REST APIs via SuiteTalk. Authentication uses OAuth 2.0 client credentials or token-based authentication (TBA), with tokens valid for 60 minutes. NetSuite supports native event subscriptions for record changes on sales orders, invoices, and vendor bills, pushing events to a webhook endpoint, though events lack built-in HMAC signatures and require IP allowlist protection. For bulk historical reads and complex queries, NetSuite offers SuiteQL. Accounts must authenticate against a tenant-specific account ID embedded in the API base URL.

How SPS Commerce works

SPS Commerce exposes EDI transactions (purchase orders, invoices, advance ship notices, inventory advice, and warehouse events) as REST API endpoints that return data wrapped in RSX 7.7.7 JSON envelopes. Authentication uses OAuth 2.0 client credentials, with tokens returned as JWTs. SPS is a pass-through network intermediary, not a source of truth, and all documents must be wrapped in RSX format. Polling is the primary pattern; webhooks are under development. Rate limits are not published, and trading partner IDs are pre-provisioned during onboarding and not discoverable via API. Cursor-based pagination is mandatory on list endpoints.

What moves between them

Data flows primarily from SPS into NetSuite. Purchase orders and order changes from retail trading partners arrive at SPS Commerce, are polled by ml-connector on a configurable interval (typically 5 to 15 minutes), unwrapped from their RSX envelopes, and written into NetSuite as purchase order records mapped to the correct vendor (identified by the trading partner ID) and cost center. Advance ship notices and inventory advice from SPS are similarly polled and converted into NetSuite inventory adjustments or receipt records. Outbound documents such as invoices and order confirmations can flow from NetSuite back to SPS on an event-driven schedule, wrapped in RSX format, for transmission to the trading partner.

How ml-connector handles it

ml-connector stores OAuth credentials for both systems encrypted and refreshes tokens when a call returns 401. On the SPS side it polls configured purchase order and fulfillment endpoints using cursor-based pagination, unwraps each RSX JSON envelope to extract the transaction payload, and validates that the trading partner ID in the order maps to a vendor already in NetSuite. On the NetSuite side it authenticates against the customer's account ID (embedded in the API base URL) and writes purchase orders, mapped to the correct cost center and delivery location. Because SPS trading partner IDs are pre-provisioned and not discoverable via API, ml-connector requires a manual mapping table (partner ID to NetSuite vendor and cost center) supplied at setup time. Rate limits on SPS are not documented, so ml-connector implements exponential backoff with jitter on 429 responses. Every record carries a full audit trail so orders can be replayed if a downstream NetSuite write fails. SPS messaging requires a 4 to 8 week certification phase with each new trading partner before documents will flow.

A real-world example

A mid-sized distributor uses Oracle NetSuite for procurement and inventory across regional warehouses, and sells to large retail chains like Walmart and Target through the SPS Commerce network. Before the integration, purchase orders from retailers arrived at SPS as EDI messages, were downloaded manually by the procurement team as JSON files, and were re-entered into NetSuite by hand, creating duplicate work and order entry errors. With SPS and NetSuite connected, each inbound purchase order from a retailer flows automatically into NetSuite, mapped to the correct warehouse cost center, and a full audit trail lets the team replay any order that failed to write due to a temporary outage. Advance ship notices from NetSuite are also sent back to SPS for transmission to the retailer, keeping the supply chain synchronized.

What you can do

Receive purchase orders from retail trading partners via SPS Commerce and write them into Oracle NetSuite mapped to the correct vendor and cost center.
Unwrap RSX JSON envelopes from SPS and extract order line items, quantities, dates, and delivery locations for NetSuite purchase order creation.
Validate trading partner IDs against a pre-configured mapping table so orders land on the correct NetSuite vendor and cost center.
Sync advance ship notices and inventory advice from SPS into NetSuite as inventory adjustments and receipt records.
Handle OAuth token refresh for both systems, cursor-based pagination on SPS, and exponential backoff on rate-limited responses.

Questions

How does ml-connector handle the RSX JSON envelope format that SPS requires?: ml-connector receives documents wrapped in RSX 7.7.7 envelopes from SPS, extracts the inner transaction payload (purchase order, ASN, inventory advice, etc), validates it against the NetSuite schema, and writes it as a native NetSuite record. On outbound, ml-connector reads from NetSuite and wraps documents in the RSX format SPS expects before posting them back.
What happens when a trading partner ID from SPS does not match a NetSuite vendor?: ml-connector requires a manual mapping table at setup time that links each SPS trading partner ID to a NetSuite vendor and cost center. If an order arrives with an unmapped partner ID, it is logged to the audit trail and quarantined so the team can review the mapping before replay.
Does ml-connector handle SPS rate limits and certification delays for new trading partners?: Yes. SPS does not publish rate limits, so ml-connector implements exponential backoff with jitter on 429 responses. For new trading partners, SPS requires a 4 to 8 week certification phase during which documents are tested in SPS before live transmission begins, and ml-connector tracks this status so orders are not attempted before the partner is certified.

Connect Oracle NetSuite and SPS Commerce

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started