The documented x402 subgraph endpoints at https://gateway.thegraph.com/api/x402/subgraphs/id/{subgraph_id} are returning HTTP 200 with {"errors":[{"message":"auth error: malformed API key"}]} instead of the documented 402 Payment Required challenge with payment requirements. CC @tmigone
This makes the x402 path unusable today even though the code shipped in PR #1170 (Apr 15) and @graphprotocol/client-x402 shipped in graph-client PR #1016 (Apr 14). Suggests /api/x402/* routes are being directed through the API-key auth middleware rather than the x402 middleware in production.
Steps to reproduce
1. Raw curl
curl -X POST https://gateway.thegraph.com/api/x402/subgraphs/id/HMuAwufqZ1YCRmzL2SfHTVkzZovC9VL2UAKhjvRqKiR1 \
-H "Content-Type: application/json" \
-d '{"query":"{ tokens(first: 3) { symbol } }"}'
Expected: HTTP 402 with payment requirements per docs (network=base, asset=USDC, amount, recipient).
Actual: HTTP 200 with {"errors":[{"message":"auth error: malformed API key"}]}.
2. Official @graphprotocol/client-x402 CLI v1.0.0
export X402_PRIVATE_KEY=0x... # wallet funded with 0.01 USDC on Base
npx graphclient-x402 "{ _meta { block { number } } }" \
--endpoint https://gateway.thegraph.com/api/x402/subgraphs/id/HMuAwufqZ1YCRmzL2SfHTVkzZovC9VL2UAKhjvRqKiR1 \
--chain base
Same response — "auth error: malformed API key". Tested against multiple subgraphs (Uniswap V3 Base HMuAwu..., Uniswap V2 Ethereum 5zvR82...) with identical results.
Other observations
https://testnet.gateway.thegraph.com (referenced in the docs as the testnet base URL) does not resolve via DNS.
- The standard API-key endpoint
https://gateway.thegraph.com/api/subgraphs/id/{id} works fine with a valid API key, confirming the underlying gateway is healthy.
Likely cause
/api/x402/* requests appear to be routing through the API-key auth middleware first, which rejects the request before the x402 middleware (src/middleware/x402_auth.rs) gets a chance to issue the 402 challenge.
Happy to test fixes against my wallet on Base mainnet.
The documented x402 subgraph endpoints at
https://gateway.thegraph.com/api/x402/subgraphs/id/{subgraph_id}are returningHTTP 200with{"errors":[{"message":"auth error: malformed API key"}]}instead of the documented402 Payment Requiredchallenge with payment requirements. CC @tmigoneThis makes the x402 path unusable today even though the code shipped in PR #1170 (Apr 15) and
@graphprotocol/client-x402shipped in graph-client PR #1016 (Apr 14). Suggests/api/x402/*routes are being directed through the API-key auth middleware rather than the x402 middleware in production.Steps to reproduce
1. Raw curl
Expected: HTTP 402 with payment requirements per docs (network=base, asset=USDC, amount, recipient).
Actual: HTTP 200 with
{"errors":[{"message":"auth error: malformed API key"}]}.2. Official
@graphprotocol/client-x402CLI v1.0.0Same response —
"auth error: malformed API key". Tested against multiple subgraphs (Uniswap V3 BaseHMuAwu..., Uniswap V2 Ethereum5zvR82...) with identical results.Other observations
https://testnet.gateway.thegraph.com(referenced in the docs as the testnet base URL) does not resolve via DNS.https://gateway.thegraph.com/api/subgraphs/id/{id}works fine with a valid API key, confirming the underlying gateway is healthy.Likely cause
/api/x402/*requests appear to be routing through the API-key auth middleware first, which rejects the request before the x402 middleware (src/middleware/x402_auth.rs) gets a chance to issue the 402 challenge.Happy to test fixes against my wallet on Base mainnet.