Production environment credentials rejected by eBay despite successful local OAuth authentication

I'm troubleshooting an eBay Production OAuth integration deployed on Vercel.

Project: rockwell-records Deployment ID: dpl_YKXpiUacBqj5pDVeKbnFz75dm97F Deployment commit: 4b6d30c

The application authenticates using the OAuth client-credentials flow.

Working test:

Direct authentication from macOS Terminal using the Production Client ID and Client Secret succeeds with HTTP 200.

eBay's Developer Portal can also generate a Production application token.

Failing tests:

The deployed Vercel function receives HTTP 401 invalid_client.

Both Node.js fetch() and https.request() fail identically.

Verified configuration:

Both required environment variables exist and are scoped to Production.

Both were updated before the current Production deployment was created.

The deployed function receives both variables.

No unexpected surrounding whitespace or quotation marks was detected.

The correct Production OAuth endpoint and scope are used.

No duplicate variable definitions or repository-level overrides were found.

The deployment is current, Ready, and correctly aliased.

Questions:

Could there be an environment-variable snapshot or propagation issue despite the deployment being created after the variable updates?

Is there a supported way to verify that a Production function is using the current encrypted environment-variable revisions without exposing their contents?

What additional diagnostic would distinguish a stored credential mismatch from a Vercel runtime configuration issue?

No credentials, authorization headers, or access tokens are included in this report.

A snapshot problem is unlikely. Vercel copies the env values into each deployment when it’s created, so a deployment made after your update has the new values. Redeploying with “Use existing Build Cache” unchecked fully rules this out. There’s no revision ID you can check, but you can compare fingerprints safely. Log crypto.createHash('sha256').update(id + ':' + secret).digest('hex').slice(0, 8) plus both lengths in the function, then run the same line locally. To tell a bad stored value from a runtime problem: run vercel env pull .env.prod --environment=production, then run your working Terminal request using those pulled values. If that gets a 401, the stored value is wrong. If it gets a 200, the function’s request is different. In that case, check that the Basic header is base64 of the raw id:secret (not URL-encoded first) and that the body is sent as form-urlencoded, not JSON.