Plex and SPS Commerce integration

What moves between them

Sales orders, invoices, and shipment notices (ASNs) flow from Plex to SPS Commerce on a configurable schedule (5 to 15 minutes recommended). Plex polls the Plex REST API for orders marked as modified since the last run, translates each order into an RSX 7.7.7 envelope, and POSTs it to SPS Commerce. Inventory advice, PO acknowledgments, and other inbound EDI documents from retail partners flow back to Plex on the same schedule. Retail partner IDs are pre-provisioned in SPS Commerce and mapped to Plex ship-to locations.

How ml-connector handles it

ml-connector stores both Plex OAuth credentials and SPS Commerce OAuth credentials encrypted and refreshes tokens as needed on each API call. On the Plex side, it polls the REST API at a configurable interval, filtering by modified_date to pick up only new and changed orders since the last poll. Each order is translated into an RSX 7.7.7 JSON envelope with the correct trading partner identifier (provisioned during SPS onboarding), then POSTed to SPS Commerce's fulfillment endpoint. SPS rate limits return HTTP 429 without documented thresholds, so ml-connector backs off and retries with exponential jitter. Inbound documents from retail partners (via SPS webhook or scheduled pull) are mapped back to Plex sales orders using the purchaseOrderNumber. Deduplication uses the Plex order number and SPS trading partner ID; documents are replayed if a downstream call fails. Plex enforces role-based access, so the integration user account must have the correct Plex role assigned before any API calls succeed.

A real-world example

A mid-sized discrete manufacturer supplies three major retail chains with consumer goods. The company runs Plex for manufacturing, planning, and finance. Before the integration, the operations team exported sales orders from the retail portals, manually keyed them into Plex, and then exported invoices and shipment notices to upload back to each retailer's portal. With Plex and SPS Commerce connected, each new retail order appears in Plex automatically, allocated to the correct warehouse and product line. When an order ships, the ASN flows back to the retail partner through SPS Commerce without manual intervention. Month-end reconciliation is faster because retail invoicing and fulfillment data are already aligned.

What you can do

• •Read sales orders from Plex and translate them into SPS Commerce RSX 7.7.7 envelope format for delivery to your retail trading partners.
• •Post invoices and advance ship notices (ASNs) from Plex shipments to SPS Commerce on a schedule you define.
• •Receive inbound EDI documents (PO acknowledgments, inventory advice, functional acknowledgments) from retail partners and map them back to Plex sales orders.
• •Authenticate with OAuth 2.0 client credentials on both Plex and SPS Commerce, handle token refresh, and manage rate limits with exponential backoff.
• •Track every document with a full audit trail, deduplicate by order number and trading partner ID, and replay any record if a downstream call fails.

Questions

Which direction does data move between Plex and SPS Commerce?

The main flow is from Plex to SPS Commerce. Sales orders, invoices, and shipment notices (ASNs) are read from Plex and posted to SPS Commerce for delivery to your retail trading partners. Inbound EDI documents (PO acknowledgments, inventory advice) flow back from SPS Commerce to Plex. Reference data such as trading partner IDs and warehouse mappings is aligned in both directions.

Why does Plex require polling instead of webhooks?

Plex does not offer native webhooks, so ml-connector polls the Plex REST API at a configurable interval (5 to 15 minutes recommended) and filters by modified_date to pick up only new and changed orders since the last poll. This pattern is standard for on-premise and legacy cloud ERP systems that do not expose a push notification capability.

What is the RSX envelope format and why does SPS Commerce require it?

RSX 7.7.7 is an extended JSON envelope standard used by SPS Commerce to wrap EDI documents (X12, EDIFACT) in a common format for API transport. SPS requires all documents to be wrapped in this envelope so the platform can route them to the correct trading partner and translate them into the partner's preferred EDI format (e.g., X12 850 for purchase orders to Walmart). ml-connector handles the envelope wrapping so you do not have to.