Troubleshooting

PunchOutSetupRequest returns 401 Unauthorized

The buyer clicks your catalogue and their system reports an authentication failure. Your endpoint logs a request but rejects it, or the buyer sees a cXML Response with a 401 status.

Short answer

This is a credential mismatch nine times out of ten, and usually not the shared secret itself — it is the domain attribute or the environment. Compare the exact Credential block the buyer sent against what you have configured, attribute by attribute, before changing anything.

Causes, most likely first

Ordered by how often each one turns out to be the culprit, not by how interesting it is. Work down the list.

  1. You are checking test credentials against production, or the reverse

    How to confirm: Look at the Identity in the From credential. Ariba test accounts use a different ANID from production, and buyers routinely send a test request to a production endpoint during setup.

    Fix: Configure both environments separately and key your credential lookup on the Identity you receive, not on a single stored value.

  2. The domain attribute does not match

    How to confirm: Your configuration expects domain="NetworkID" and the buyer is sending domain="DUNS", or a buyer-specific value. The Identity may be correct while the domain is not, which is why this one is missed so often.

    Fix: Match on the domain and Identity pair, not on Identity alone. Ask the buyer to confirm which domain value their system sends.

  3. The shared secret has whitespace or encoding damage

    How to confirm: Secrets get copied out of emails and spreadsheets. A trailing newline or a smart-quote substitution is invisible in most log output. Compare byte lengths rather than eyeballing the strings.

    Fix: Trim on both ends before comparing, and have the buyer re-issue the secret through their portal rather than sending it in a message.

  4. You are comparing the wrong Credential block

    How to confirm: A cXML header carries From, To and Sender. The SharedSecret lives in Sender. Authenticating against the From credential looks correct and fails for requests that are otherwise fine.

    Fix: Authenticate on Sender. Use From to identify which buyer organisation is shopping.

  5. The buyer has not finished their side of the configuration

    How to confirm: If your logs show no inbound request at all, the 401 is being generated inside their system before it ever reaches you.

    Fix: Ask them to confirm the endpoint URL they have stored and whether the relationship is active. On Ariba this is frequently an unaccepted relationship request.

If it is not on your side

If your logs show the request arriving and the credentials matching, send the buyer the payloadID and timestamp of the request you received, plus the credential domain and Identity you matched on. That is enough for their team to find the same transaction on their side, and it moves the conversation off "it does not work".

Check the document itself

Paste your cXML or OCI payload into our free tester. It runs entirely in your browser and reports the structural problems buyers reject on.

Open the tester

Related questions

Should the shared secret comparison be case sensitive?

Treat it as case sensitive — it is a secret, not an identifier. If a case-insensitive comparison is the only way your integration passes, something else is wrong and you are masking it.

The buyer says their credentials are correct. Now what?

They usually are. The mismatch is normally in the domain attribute or in which environment the request came from, neither of which the buyer-side administrator can see from their configuration screen. Send them the exact credential block you received, with the secret redacted.

Other failures

Rather not be the one debugging this?

We build and run the endpoint, and deal with the buyer’s technical team directly. Pricing is published in full.

See pricing Send us the error