We are integrating Kimi K2.5 into RAI PACS, a radiology AI platform. Our Open Platform account has been recharged successfully and currently shows a $105 balance, but every API key created from platform.kimi.ai returns HTTP 401 Invalid Authentication.
Confirmed the keys were created on platform.kimi.ai
Confirmed the endpoint region matches the Open Platform account
Confirmed the Authorization: Bearer header and removed whitespace
Tested newly generated keys after the recharge
Tested both model listing and chat completions
Confirmed available account balance
All attempts produce the same 401 response. Has anyone seen an account-level activation delay or another permission step after recharge? Could the Kimi team please verify whether API access needs to be enabled for this account?
We have also contacted the official support address from [email protected]. No API key secrets are included in this post.
Thanks for the detailed report — the structured troubleshooting list is genuinely helpful, and we’ve gone through each item.
To answer your main question directly: no, there is no account-level activation delay after a recharge. API access takes effect immediately, and there’s no separate permission step that needs to be enabled for your account. Since your balance is already showing, your keys should be working — which points the investigation at the request itself rather than account status.
One detail in your list stands out: the “removed whitespace” step. The Authorization header requires exactly one space between Bearer and the key:
Authorization: Bearer sk-xxx
If the whitespace cleanup also collapsed that space (e.g., Bearersk-xxx), every request would return exactly the 401 Invalid Authentication you’re seeing, no matter how fresh the key is.
Could you run this minimal test directly from a terminal, replacing sk-xxx with your full key?
If this returns the model list, the key and account are fine, and the issue is in how the integration constructs the header — worth checking that code path for over-aggressive trimming or encoding.
If it still returns 401 with the header exactly as above, let us know the result here (please don’t paste the key itself) and we’ll take it from there.
We confirmed the key has no leading/trailing whitespace or newline. We also tested a newly generated key, the chat completions endpoint with kimi-k2.5, and the suggested api.moonshot.cn endpoint; all return the same 401. The same result occurs from a direct terminal request and our Vercel production runtime.
For security, we have not posted the secret. The affected key IDs were provided to the official support team, who are also investigating the account/region association. Since the exact minimal header still fails, what diagnostic should we provide next without exposing the secret publicly?