Groq
Connect AISIX AI Gateway to Groq so applications can call Groq-hosted models through the gateway's OpenAI-compatible API. AISIX keeps the Groq credential on the gateway side. It authorizes model access with caller API keys and allowlists, and applies the same rate-limit and usage-accounting controls as other model aliases.
Groq exposes an OpenAI-compatible API, so it uses the openai adapter with a Groq api_base.
Prerequisites
The following examples use a self-hosted AISIX gateway. Before configuring the upstream, prepare the following:
- A running AISIX gateway with the Admin API and proxy API available. Commands use the Quickstart listener addresses; substitute your configured addresses if needed.
- The admin key from the gateway
config.yaml. - A Groq API key from the Groq Console.
Configure the Groq Upstream
Create a provider key, model alias, and caller API key for the Groq-backed chat-completions route.
Create a Provider Key
Create the provider key that stores the Groq credential and API root:
# Replace with your values
export AISIX_ADMIN_KEY="YOUR_ADMIN_KEY"
export GROQ_API_KEY="YOUR_PROVIDER_API_KEY"
curl -sS -X POST "http://127.0.0.1:3001/admin/v1/provider_keys" \
-H "Authorization: Bearer ${AISIX_ADMIN_KEY}" \
-H "Content-Type: application/json" \
--data-binary @- <<EOF
{
"display_name": "groq-prod",
"provider": "groq",
"adapter": "openai",
"secret": "${GROQ_API_KEY}",
"api_base": "https://api.groq.com/openai/v1"
}
EOF
❶ provider is groq.
❷ adapter is openai, because Groq accepts OpenAI chat-completions requests.
❸ secret stores the Groq API key. It follows the credential-handling behavior in Provider Credentials.
❹ api_base is required and already includes the /openai/v1 path. AISIX appends /chat/completions to it.
Copy the returned provider key ID.
Create a Model
Groq model availability changes over time. Check the Groq models list for a current model ID before creating a model alias.
Create the model alias callers will send in requests:
# Replace with your values
export PROVIDER_KEY_ID="YOUR_PROVIDER_KEY_ID"
curl -sS -X POST "http://127.0.0.1:3001/admin/v1/models" \
-H "Authorization: Bearer ${AISIX_ADMIN_KEY}" \
-H "Content-Type: application/json" \
--data-binary @- <<EOF
{
"display_name": "groq-gptoss-prod",
"provider": "groq",
"model_name": "openai/gpt-oss-120b",
"provider_key_id": "${PROVIDER_KEY_ID}"
}
EOF
❶ display_name is the alias callers send in model.
❷ model_name is the Groq model ID, for example openai/gpt-oss-120b.
❸ provider_key_id attaches the alias to the Groq provider key.
Create a Caller API Key
Choose the caller API key value that the application will send to AISIX, then hash it for the admin resource:
# Replace with your values
export AISIX_API_KEY="YOUR_CALLER_API_KEY"
CALLER_KEY_HASH=$(printf '%s' "${AISIX_API_KEY}" | shasum -a 256 | awk '{print $1}')
Create the caller API key resource that can access the model alias:
curl -sS -X POST "http://127.0.0.1:3001/admin/v1/apikeys" \
-H "Authorization: Bearer ${AISIX_ADMIN_KEY}" \
-H "Content-Type: application/json" \
--data-binary @- <<EOF
{
"key_hash": "${CALLER_KEY_HASH}",
"allowed_models": ["groq-gptoss-prod"]
}
EOF
The allowed_models value must match the model alias you created.
Verify the Provider Connection
Send a chat-completions request through the AISIX proxy:
curl -sS -X POST "http://127.0.0.1:3000/v1/chat/completions" \
-H "Authorization: Bearer ${AISIX_API_KEY}" \
-H "Content-Type: application/json" \
-d '{
"model": "groq-gptoss-prod",
"messages": [
{
"role": "user",
"content": "Say hello from Groq."
}
]
}'
The gateway returns an OpenAI-compatible response that echoes the caller-facing alias groq-gptoss-prod. If the request fails, check the provider key secret, api_base, and the Groq model ID in model_name.
Next Steps
You have now connected AISIX to Groq and verified the model alias. Continue with these guides:
- Model Aliases: add routing, cost metadata, and rate limits for this alias.
- Routing and Failover: fail over between Groq and a second provider.
- Provider-Specific Overrides: adapt request and response shapes when an upstream API differs from its adapter.
- Provider Compatibility: review supported proxy endpoints and provider-specific boundaries.