User Manual
Help Center/User Manual/Connect SPS Commerce: EDI orders in, ASNs and invoices out

Connect SPS Commerce: EDI orders in, ASNs and invoices out

Last updated 2026-11-01

Copy the API Base URL from your SPS onboarding documents, take the Client ID and Client Secret issued together when your SPS account was opened, paste all three into Integration, test, map each trading partner, and activate — 850 orders flow in and 856 / 810 documents flow out.

The SPS Commerce connector exchanges EDI documents with your retail trading partners through SPS Commerce (RSX / API): inbound documents such as 850 purchase orders come in from partners and become orders, and outbound documents such as 856 advance ship notices and 810 invoices go back out to the same partners. It is not a store connection and there is no store authorisation — everything is organised by trading partner and by document type, so each partner is set up and checked on its own.

SPS Commerce connection steps: base URL and credentials first, then test, then trading partner mapping, then activate.

Prerequisites#

  • An SPS Commerce account that has been opened with API access. Your credentials and your API Base URL come from that opening — they are not created inside Integration.
  • Your SPS onboarding documents. They state the API Base URL for your account and carry the Client ID and Client Secret issued for your API access — keep them at hand for the next two steps.
  • At least one trading partner to exchange documents with through SPS Commerce, and a clear list of which document types you will exchange with that partner — for example 850 purchase orders in, and 856 and 810 out. This connection does not create the partner for you.
  • For the first connection, prove the setup with one partner and one document type first — never try a new mapping on live partner documents.

Get your credentials#

  1. Find the API Base URL in your SPS onboarding documents and copy it exactly as written. Every endpoint the connection uses, including the OAuth token endpoint, is relative to this base address, so a copied address with a missing or extra part will not work.
  2. Find the Client ID and the Client Secret in the same onboarding materials. They were issued together, as a pair, when your SPS account was opened with API access — keep the pair together and do not mix in credentials from a different account.
  3. There is no self-service page where you generate these credentials yourself. If the Client Secret is lost or was never handed over, contact the SPS contact who handled your account opening and ask them to reissue it — do not try to create a replacement somewhere else.
  4. Keep all three values together for the next step: the API Base URL, the Client ID and the Client Secret. The test in a later step needs all three, and leaving any one out is reported as a missing value.

Fill it into Integration#

  1. Open Integration → Connector Marketplace → SPS Commerce → New connection.
  2. API Base URL (base_url) — required: paste the API base address exactly as it appears in your SPS onboarding documents. Do not leave this field empty and do not substitute a general SPS website address: the connection talks to this base address, and without it the test stops before it even tries your credentials.
  3. Client ID (client_id) — required: paste the Client ID issued for your account at SPS account opening. Take care not to paste the Client Secret into this field — the two values are a pair, and each belongs in its own field.
  4. Client Secret (client_secret) — required: paste the Client Secret issued together with the Client ID. It is stored encrypted and is never shown back after you save, so paste it carefully and keep your own copy in the onboarding materials.

Test the connection#

Click Test connection. The test first checks that the API Base URL, Client ID and Client Secret are all present, then uses them to exchange an OAuth token with SPS — it asks SPS for a token and confirms one comes back. The test does not pull any EDI documents. A pass therefore proves only that the base address and the credential pair are usable; it does not mean your trading partners or your document mapping are set up yet — that is the next step.

Mapping / pick a template#

Mapping on SPS Commerce is done per trading partner and per document type — there is no single mapping that covers every partner, because each retail partner can require different fields and rules on the same document type. For each partner, pick the template for the document types you exchange with them and check the mapping side by side: on inbound 850 purchase orders, the order number, line items, quantities and ship-to details land on the standard order; on outbound documents such as 856 advance ship notices and 810 invoices, the shipment and invoice details are mapped back into the partner’s expected format. If a partner asks for a field your usual documents do not carry, add it in that partner’s mapping instead of changing everyone else’s. Go through each partner you plan to trade with before you activate — a partner without a finished mapping will not exchange documents, even when the connection test passes.

SPS Commerce document round-trip: 850 orders in through SPS, 856 and 810 documents back out to the partner.

Activate#

After activation, Integration exchanges documents with each mapped trading partner through SPS Commerce: inbound documents such as 850 purchase orders are pulled in and become orders, and outbound documents such as 856 advance ship notices and 810 invoices are sent back out as fulfilment and billing progress. Partners whose mapping is not finished do not start exchanging just because the connection is active. Watch the first documents for each partner in Runs / Logs before trusting the flow unattended.

FAQ#

Test stops and says the API Base URL is missing

The base_url field was left empty. This field is easy to miss, because the SPS connection needs three values, not two — without the base address the connection does not know where to talk to, so the test stops before checking your credentials.

Copy the API Base URL from your SPS onboarding documents exactly as written, paste it into the API Base URL field, save, and run the test again. If the address in your documents looks incomplete, ask your SPS account-opening contact to confirm it rather than guessing the rest.

Test fails on the token exchange — authentication does not pass

SPS did not return a token for the values you entered. In plain terms, the base address, the Client ID and the Client Secret do not match each other: the base address may be copied wrong, the Client ID and Client Secret may be swapped between their two fields, the secret may have been reissued since your copy was made, or the pair may belong to a different SPS account.

Re-copy all three values from your SPS onboarding documents, checking that the Client ID goes into the Client ID field and the Client Secret into the Client Secret field, then test again. If it still fails, contact the SPS contact who handled your account opening and ask them to confirm the base address and reissue the secret if needed — there is no self-service page where you can reset it yourself.

Test passes, but no 850 orders arrive

This usually does not mean the connection is broken. The test only exchanges a token — it never pulls a document — so a pass says nothing about orders. Orders stay missing when the trading partner’s mapping is not finished, when that partner and its 850 document type are not part of your active setup, or when the partner simply has not sent any new orders yet.

Finish the mapping for that partner and its 850 document type, make sure the connection is activated, and check Runs / Logs for that partner. If everything is set and the partner confirms an order was sent, use the time the partner sent it to look up that document in Runs / Logs.

Outbound 856 / 810 documents are rejected by the partner

The connection and the token are fine — the document itself does not match what this partner expects. Each retail partner can require its own fields and rules on 856 and 810 documents, so a mapping that works for one partner can still miss a field another partner requires, or carry a value in a form that partner does not accept.

Compare the rejected document against that partner’s requirements, add or correct the fields in that partner’s mapping only, and resend one document to confirm before letting the rest flow. Do not change the shared mapping for every partner to fix one partner’s rejection.