Walmart.io Affiliate API: Production public key upload silently fails, Stage key works but API rejects it with "Public Key not found wm_svc.env: prod"

I'm integrating with the Walmart.io Affiliate Product API (Store Locator + Product Lookup endpoints under `/api-proxy/service/affil/product/v2/`).

The auth scheme is RSA-signed request headers (`WM_CONSUMER.ID`, `WM_CONSUMER.INTIMESTAMP`, `WM_SEC.KEY_VERSION`, `WM_SEC.AUTH_SIGNATURE`), per Walmart's docs.

I can get this working end-to-end against a Stage Consumer ID, but the API itself only appears to recognize Production credentials — and uploading a Production key silently fails in the walmart.io portal.

I found [a related closed question] with the same symptom but no debugging detail, so here's a fuller writeup.

Setup

1. Generated a 2048-bit RSA key pair locally:
   
   openssl genrsa -out wm_private.pem 2048
   openssl rsa -in wm_private.pem -pubout -out wm_public.pem
   
2. Created an application on walmart.io under the **Affiliate** product.
3. Uploaded `wm_public.pem` via the "Upload Public Key" form with **Environment Type = Sandbox** → succeeded, and the app's Details page now shows a **Stage Consumer ID** (Key Version 1).
4. Uploaded the *same* public key (also tried freshly generated key pairs, and a second application from scratch) with **Environment Type = Production** → the UI shows a blank modal with just a "Close" button. No error text, no success confirmation.

What the network tab shows on the failing Production upload

The `create`/upload XHR request returns **HTTP 200**, but the JSON body itself signals failure with no further detail:

json
{
  "hasError": true,
  "errorCode": null,
  "errorDescription": null
}

A follow-up call to list the account's applications/keys confirms nothing was actually registered for Production — the app's Details page permanently shows "Prod Consumer ID (Key version: )" — empty, no key version — while the Stage Consumer ID field is populated correctly.

What happens when I call the actual API with the (successfully issued) Stage Consumer ID

Per the docs, the only documented base URL is `https://developer.api.walmart.com/api-proxy/service/affil/product/v2`. I signed a request manually with OpenSSL to rule out any bug in my client code:

CONSUMER_ID="<my-stage-consumer-id>"
KEY_VERSION="1"
TIMESTAMP=$(($(date +%s%N)/1000000))
TO_SIGN="${CONSUMER_ID}
${TIMESTAMP}
${KEY_VERSION}
"
printf '%s' "$TO_SIGN" > to_sign.txt
openssl dgst -sha256 -sign wm_private.pem -out sig.bin to_sign.txt
SIGNATURE=$(openssl base64 -A -in sig.bin)

curl -s --compressed "https://developer.api.walmart.com/api-proxy/service/affil/product/v2/stores?zip=63049" \
  -H "WM_CONSUMER.ID: $CONSUMER_ID" \
  -H "WM_CONSUMER.INTIMESTAMP: $TIMESTAMP" \
  -H "WM_SEC.KEY_VERSION: $KEY_VERSION" \
  -H "WM_SEC.AUTH_SIGNATURE: $SIGNATURE"

Response: HTTP 401 Unauthorized

json

{"details":{"Description":"Public Key not found for  Consumer id : <my-stage-consumer-id>","wm_svc.version":"2.0.0","wm_svc.name":"affil-product","wm_svc.env":"prod"}}

Note the response header `Wm_svc.env: prod` — the only endpoint documented for this API is a Production-only service, so a Stage Consumer ID is (unsurprisingly) not recognized there. But since Production key upload never succeeds, I have no way to get a Consumer ID this endpoint will actually accept.

Question

- Is there a documented Sandbox/Stage base URL for the Affiliate Product API (stores/items endpoints), distinct from `developer.api.walmart.com`, that Stage credentials are meant to be used against? I haven't found one in the docs.

- If Production is the only real environment for this API, what's required to get a Production public key upload to actually succeed? Is there an account-level approval/entitlement gate that has to happen before the portal will accept a Production key (separate from the initial Affiliate product approval, which I already have)?

- Has anyone gotten Production key upload to work on this portal, and if so, what was different about their account/application setup?

I've filed a support ticket through the walmart.io portal describing this exact behavior and am waiting on a response, but wanted to check here in case this is a known issue/gap with a documented workaround.