I tested GET /v1/organization/admin_api_keys on my side with an Admin API key and it’s returning successfully, so the endpoint itself seems to be working.
Since your other org endpoints are working, this looks like something subtle in the request rather than permissions. A few things that are worth double-checking:
Exact path match – this endpoint is strict; even a small difference like a trailing slash (/admin_api_keys/) or typo can return a 404
Base URL – confirm you’re hitting https://api.openai.com/v1/organization/admin_api_keys exactly (no alternate base URL or proxy rewriting the path)
Key type – worth re-validating that the key being used at runtime is still an Admin key (especially if multiple keys/env vars are in play)
One quick sanity check: try running the curl command directly in a clean environment (no wrappers, no proxies) and see if the result changes.
500
{
"error": {
"message": "The server had an error while processing your request. Sorry about that!",
"type": "server_error",
"param": null,
"code": null
}
}
request-id: ec0e3b9e-3f16-4155-b2de-16840421ea25
request-id: 82de595d-beba-4881-b6bb-8bab5522490c
If not sending “name”, you get a 400 error about the missing parameter as body message, so it is alive.
Admin keys making admin keys does seem a strange delegation, though. Perhaps this is reserved for enterprise partners with another superuser? Audit logging might be another dependency.