Credential Types Matrix

Compare which credential shape each AISIX provider integration accepts: static API keys, structured multi-field credentials, and temporary or minted tokens.

Most AISIX provider integrations store a single static API key and send it as a bearer token or a vendor-specific header. A few accept a structured, multi-field credential instead, and two of those can avoid a long-lived static secret altogether. This page compares the credential shape across providers so you do not have to open every provider guide to answer "does this one support anything other than a static key."

For how AISIX stores whatever credential you provide, see Credential Handling. This page is about what shape the credential takes before it reaches that storage layer.

Credential Shapes AISIX Supports

Shape	What it looks like	Who accepts it
Static API key	A single bearer token or vendor header value, stored as `api_key`	Every direct, community catalog, and self-hosted provider not listed below — this is the default shape
Structured multi-field credential	A JSON object with multiple named fields, stored under `config` (AISIX Enterprise) or serialized as an `api_key` JSON string (AISIX OSS)	AWS Bedrock, Google Vertex AI, Azure OpenAI (Entra ID option only)
Temporary, caller-supplied credential	A structured credential whose fields include a short-lived token you refresh yourself	AWS Bedrock with an STS `session_token`
Temporary, AISIX-minted credential	AISIX exchanges a long-lived credential for a short-lived access token itself and refreshes it before expiry	Google Vertex AI with `service_account_json`

Provider-by-Provider Comparison

Provider	Credential fields	Temporary credential support	Notes
OpenAI and most direct, community catalog, and self-hosted providers	`api_key` (static)	Not supported	Single bearer token or vendor header, sent as-is.
Azure OpenAI	`api_key` (resource API key, static) or a `{tenant_id, client_id, client_secret}` Entra ID app-registration credential	Not supported — the Entra ID credential is a static client secret that AISIX exchanges for a bearer token per request, not a rotating managed identity	Choose the resource API key or the Entra ID credential per provider key; see Use Entra ID Authentication.
AWS Bedrock	`{access_key_id, secret_access_key, region}`, plus optional `session_token`	Supported — include `session_token` for temporary STS credentials; omit it for long-lived static IAM user keys	You refresh the STS token yourself; AISIX does not mint or renew it.
Google Vertex AI	`service_account_json` (a service-account key) or `access_token` (a token you mint and refresh yourself)	Effectively supported through `service_account_json` — AISIX signs a JWT, mints an OAuth token, caches it, and refreshes it before expiry	AISIX does not discover Application Default Credentials, metadata-server credentials, or Workload Identity Federation — you must supply one of the two fields above explicitly.

What AISIX Does Not Do

No provider integration currently authenticates by discovering ambient cloud identity — an EC2 instance role, a GKE or EKS workload identity, or an Azure managed identity — the way a workload running natively on that cloud might. Every credential above is a value you generate and hand to AISIX explicitly, whether that value is a static key, a structured multi-field credential, or a service-account key AISIX exchanges for a token on your behalf. If your organization's policy requires avoiding long-lived static secrets entirely, Bedrock's STS session_token support and Vertex's service_account_json token-minting are the two paths available today; every other provider integration is a static key.

Next Steps

Credential Handling — how AISIX Enterprise and AISIX OSS each store whichever credential shape you provide.
Provider Key Rotation — rotate a provider credential in place or gradually, regardless of its shape.
api_base Troubleshooting — the other field that recurs across provider setup problems.