🔍 What This Article Covers
Some customers using the MCP (Model Context Protocol) endpoint with a valid v2 X-API-KEY header experienced requests that hung indefinitely — never returning a response, not even an error. At the same time, requests sent without an API key returned a fast 401 Unauthorized error, which confirmed the endpoint itself was reachable.
This article explains what caused the issue, confirms it has been resolved, and tells you what to do if you still experience hanging requests.
⚙️ Root Cause: Redis Timeout During v1→v2 Migration
This was a confirmed systemic issue, tracked internally as SPE-1065. During the migration from the legacy v1 API key system to the new v2 system, the allow-list check — the step that validates whether a key is permitted to access the MCP endpoint — relied on a shared Redis instance. A timeout in that Redis connection caused the allow-list check to stall on every MCP pod simultaneously.
The result: any request carrying a v2 X-API-KEY header would pause at the authentication step and never complete. Requests with no key bypassed that check entirely and received an immediate 401, which is why those returned quickly.
This was not caused by an invalid or revoked key. The key itself was valid — the authentication infrastructure was unable to verify it due to the Redis timeout.
✅ Current Status: Resolved
The engineering team identified the root cause, reviewed the fix, and deployed it to production. MCP v2 API key authentication is now functioning correctly. The allow-list check is reachable from all MCP pods and no longer times out.
🚀 Steps to Take If You Are Still Experiencing Hanging Requests
- Confirm you are using a v2 API key. Legacy v1 keys are no longer supported for MCP endpoint access. If you are unsure which version your key is, check your API key settings in your account.
- Retry your request. Now that the fix has been deployed, a fresh request using a valid v2 X-API-KEY header should authenticate and respond correctly.
- Check for any network-level timeouts on your side. If your client or infrastructure has a short timeout configured, ensure it is set high enough to allow the server to respond (a few seconds is typically sufficient).
- Verify the key has not been revoked. If your key was deactivated or flagged, requests may fail. If you suspect your key status has changed, review it in your account settings or generate a new one.
- Test with and without the header. If requests without the key still return a fast 401 but requests with the key still hang, this is a strong signal that something is still wrong server-side — not on your end. In this case, contact our team immediately (see below).
💡 What a Hanging Request Looks Like vs. a Normal Failure
- Hanging request (the bug): Request with a valid v2 X-API-KEY header — no response, no error, connection stays open indefinitely.
- Normal auth failure: Request without a key — fast 401 response, connection closes immediately.
- Expected behavior (post-fix): Request with a valid v2 X-API-KEY header — authenticated successfully, response received within a normal timeframe.
📋 Information to Have Ready If You Need Support
If you still experience hanging requests after the fix, gather the following before contacting our team — it will significantly speed up the investigation:
- A description of the exact request being made (endpoint path, headers used — redact the key value itself)
- Timestamps of when the hanging requests occurred
- Whether requests without the key return a fast 401 at the same time
- Any error messages or timeout messages from your client or logs
- A screen recording or HAR file if possible
💬 Still Need Help?
If you need further assistance, open the chat widget in the bottom-right corner of the platform and type human teammate to be connected with a member of our team.