Our Square Production access token works in Square API Explorer, including:
But the same token returns 401 UNAUTHORIZED from our AWS Amplify server in us-east-2.
We confirmed the live server reads the current token from AWS Parameter Store. Its SHA-256 token fingerprint is 79d4b8f8503e, which matches the fingerprint of the current Production token. The server calls the Production endpoint:
https://connect.squareup.com/v2/locations
and receives:
UNAUTHORIZED (HTTP 401): This request could not be authorized.
The same happens when our app tries to create a payment link.
Square application ID: sq0idp-tdlYm8ePWVWFWuCB1h6U-g
Location ID: LJ3WVA30ZJ49G
Approximate failing time: September 18, 2026, around 7:12 AM America/New_York.
Can Square please check why requests from our Amplify-hosted server are rejected while Square API Explorer accepts the matching Production token?
I have not included the access token itself for security.
Something on your end is stripping or never adding the Authorization: Bearer XXXXX header. Our logs show a bunch of 401s with errors pointing to no auth header.
Our deployed AWS production server sends these headers to Square:
For GET ``https://connect.squareup.com/v2/locations:
Authorization: Bearer [production token redacted]
Square-Version: 2026-09-16
For POST ``https://connect.squareup.com/v2/online-checkout/payment-links:
Authorization: Bearer [production token redacted]
Square-Version: 2026-09-16
Content-Type: application/json
The server sends these through Node’s direct HTTPS client. The production token is trimmed before use, read at runtime from AWS Parameter Store, and its safe fingerprint matches the token that succeeds in API Explorer.
Can you confirm which of these headers Square receives for the requests around 11:14 AM Eastern on September 18, and provide the request ID or timestamp for each?
Authorization: Bearer [production token redacted]
Square-Version: 2026-09-16
Authorization: Bearer [production token redacted]
Square-Version: 2026-09-16
Content-Type: application/json
I verified that your production endpoint and request shape are correct: production requests should go to https://connect.squareup.com/v2 and include the production token as Authorization: Bearer {access_token}.
Our internal telemetry for the reported time window shows authorization-layer 401 events for GET /v2/locations and POST /v2/online-checkout/payment-links with the messages correlated to missing credential headers for an authenticated route
However, those entries do not include your application ID, token fingerprint, or a confirmed customer-facing Square request ID. They are also high-volume route-level events, so I cannot definitively attribute them to your requests.
I checked your application’s API Logs in the application dashboard, and cannot see any requests made there so I am unable to tie a specific request to your application directly.
Could you please reproduce the issue once from the production server and capture the complete sanitized response (no access token) including:
- exact UTC timestamp, including milliseconds
- HTTP method, path, and destination hostname
- HTTP status
- full response headers and body
- especially the
x-square-request-id response header, if present
- a locally generated correlation ID
- the token fingerprint only (never the token itself)
If x-square-request-id is not returned, please provide the complete response headers and exact timestamp anyway. With that information, we can correlate the specific request and determine whether the Authorization header was lost, altered, or not recognized before Square’s application-level logging.
Resolved — thank you for the guidance.
The authorization problem was resolved after correcting the production endpoint and redeploying. The remaining 404 was caused by our app using outdated subscription-plan variation IDs. We created fixed-price production variations, updated the deployed configuration, and Square Checkout now opens successfully.
No further investigation is needed on this case.