Skip to content

[FEATURE REQUEST] Public API for programmatic API key management (create, list, revoke) #36

@TWhidden

Description

@TWhidden

Feature Request: Programmatic API Key Management

Background

We are building a multi-tenant SaaS application that integrates xAI's Grok API as a core feature.
We provision separate API keys per customer so that each customer has isolated billing, ACL control,
and can be independently enabled/disabled. Today, this process requires us to manually log into
console.x.ai for every customer we onboard or offboard — which does not scale.

What We Need

We need public protobuf definitions (and ideally a matching REST API) for an API key management
service, covering at minimum:

  • Create a new API key (with name, optional ACL scopes, optional team assignment)
  • List existing API keys for a team
  • Revoke / Delete an API key by ID

Why This Is Needed

We know the internal infrastructure for this already exists — the console itself uses a gRPC-web
service called auth_mgmt.AuthManagement with methods including CreateApiKey, ListApiKeys,
and CheckApiKeyPropagation. We observed these in browser DevTools. However:

  • The service is not routed on api.x.ai (returns grpc-status: 5 NOT_FOUND)
  • The protobuf definitions are not published in this repo
  • It requires browser session authentication, not API key bearer auth
  • The official Python SDK (auth.py) only wraps the read-only get_api_key_info method

Proposed Additions to This Repo

A new proto file — for example proto/xai/api/v1/key_management.proto or
proto/xai/management_api/v1/auth.proto — defining something like:

syntax = "proto3";
package xai_mgmt;

service ApiKeyManagement {
  // Create a new API key for the authenticated team.
  rpc CreateApiKey(CreateApiKeyReq) returns (CreateApiKeyResp) {}

  // List all API keys belonging to the authenticated team.
  rpc ListApiKeys(ListApiKeysReq) returns (ListApiKeysResp) {}

  // Revoke (permanently delete) an API key by its ID.
  rpc RevokeApiKey(RevokeApiKeyReq) returns (RevokeApiKeyResp) {}
}

message CreateApiKeyReq {
  string name = 1;              // Human-readable name (max 127 chars)
  repeated string acls = 2;     // Optional ACL scopes (default: all)
}

message CreateApiKeyResp {
  string api_key = 1;           // Full API key (only returned once at creation)
  ApiKeyInfo info = 2;
}

message ListApiKeysReq {}

message ListApiKeysResp {
  repeated ApiKeyInfo keys = 1;
}

message RevokeApiKeyReq {
  string api_key_id = 1;
}

message RevokeApiKeyResp {}

Bonus: REST API Expansion
In addition to the gRPC surface, we would greatly benefit from REST equivalents so teams not using
the gRPC SDK can also automate key lifecycle management:

Method Path Description
POST /v1/api-keys Create a new API key
GET /v1/api-keys List all API keys for the team
DELETE /v1/api-keys/{api_key_id} Revoke an API key
Today, GET /v1/api-key (singular) returns info about the calling key only. Expanding to allow
listing and managing all keys on a team would make the REST API feature-complete for automation.

Current Workaround
Manual console login per customer. Not scalable for any SaaS operator.

Impact
This is a blocking issue for any multi-tenant operator who wants to automate customer onboarding
and offboarding. Without programmatic key management, xAI's API cannot be embedded as a
white-label service at scale.

We are happy to validate early protobuf definitions or REST proposals against our use case — please
feel free to reach out.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions