Identifiers and Key Formats

This page is the canonical reference for every prefix, identifier format, and key type used across Axemere Gateway. When you see a string starting with wl_, mgk_, or mvgc_k_, this is where to look up what it is and where it belongs.

Key and Token Prefixes
Resource ID Prefixes
Wire-Level Names
Terminology

Key and Token Prefixes

These prefixes identify the type and intended use of every secret credential in the system.

Prefix	Name	Used for	Created in
`mvgc_k_`	Gateway Key	Authenticating AI requests to the gateway proxy	Console → Gateway → Gateway Keys
`mvgc_d_`	Delegation Token	Scoped sub-authorizations for specific workloads	Programmatically via the Management API
`mgk_`	Management API Key	REST Management API automation and CI/CD pipelines	console.axemere.ai/automation → Management API tab
`mcpk_`	MCP Key	Claude Desktop, Claude Code, and MCP client connections	console.axemere.ai/automation → MCP Server tab

Key format

mgk_ and mcpk_ keys are followed by a 43-character URL-safe base64 secret. The display prefix shown in the console is the first 16 characters of the full key (e.g. mgk_a1b2c3d4e5f6g7h8), enough to identify a key without exposing the secret.

All key values are shown once at creation and cannot be retrieved again. If lost, revoke the key and create a replacement.

Resource ID Prefixes

These prefixes appear in API request bodies, configuration files, and console URLs.

Prefix	Resource	Example
`wl_`	Workload	`wl_prod_app`, `wl_chatbot`, `wl_data-pipeline`
`prj_`	Project	`prj_backend-team`, `prj_data-science`
`cred_`	Credential	`cred_openai_prod`, `cred_anthropic_dev`

Resource IDs are set by you at creation time. Use descriptive names; IDs appear in execution records, policy bundles, and spend attribution reports, so human-readable IDs make filtering and auditing significantly easier.

Naming convention: <prefix><service>-<environment> works well for most teams:

wl_billing-api-prod
wl_support-bot-dev
prj_platform-team
cred_openai-prod

Wire-Level Names

These identifiers appear in HTTP headers, environment variables, and configuration files on deployed gateways. They are stable and will not change between gateway versions.

Name	Type	Purpose
`MVGC_ADMIN_TOKEN`	Environment variable	Gateway admin API authentication
`MVGC_CP_ADDR`	Environment variable	Control Plane gRPC address
`MVGC_GATEWAY_MODE`	Environment variable	Gateway operating mode
`X-MVGC-Org-Id`	HTTP header	Org identifier forwarded on proxied requests
`X-MVGC-Workload-Id`	HTTP header	Workload identifier forwarded on proxied requests
`MVGC-Admin-Token`	HTTP header	Admin API authentication (alternative to env var)

See the Gateway Configuration Reference for the full list of environment variables and configuration keys.

Terminology

Quick reference for terms that are sometimes confused:

Term	Meaning	Do not confuse with
Gateway Key (`mvgc_k_`)	Token a workload sends when routing AI requests through the gateway	Management API Key, which manages the gateway itself
Management API Key (`mgk_`)	Token used by automation scripts to call the Management REST API	Gateway Key, which is for AI request proxying
MCP Key (`mcpk_`)	Token used by Claude clients to connect to the MCP server	Management API Key: these keys are rejected by the REST API
Credential	A provider API key (e.g. OpenAI key) stored inside the gateway on your behalf	Gateway Key, which authenticates to the gateway, not to the provider
Delegation Token (`mvgc_d_`)	A scoped token derived from a Gateway Key for specific workload contexts	Not the same as a Gateway Key: it is derived from one
Workload	Named configuration context for an AI request path (policy, project, rate limits)	Project: workloads carry runtime policy; projects carry attribution