GLM (Z.ai) API key setup

Published 2026-10-09 · Updated 2026-10-21

Z.ai, the international face of Zhipu’s GLM models, issues keys in an unusual two-part format: 32 hex characters, a dot, then 16 alphanumeric characters. The first half is a key id, the second is the secret; you send the whole thing, dot included.

Setup

export ZAI_API_KEY="0123456789abcdef0123456789abcdef.A1b2C3d4E5f6G7h8"

Base URL for the OpenAI-compatible API: https://api.z.ai/api/paas/v4. There’s also an Anthropic-compatible endpoint at https://api.z.ai/api/anthropic for tools that speak Claude’s protocol.

Verify

curl https://api.z.ai/api/paas/v4/models \
  -H "Authorization: Bearer $ZAI_API_KEY"

Python

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.environ["ZAI_API_KEY"],
    base_url="https://api.z.ai/api/paas/v4",
)

resp = client.chat.completions.create(
    model="glm-5.1",
    messages=[{"role": "user", "content": "Say hello"}],
)
print(resp.choices[0].message.content)

Gotchas

• Two consoles. z.ai (international) and bigmodel.cn (domestic China) issue keys against different endpoints. A key from one won’t authenticate on the other.
• The dot is part of the key. Truncating after the dot, or URL-encoding it, both produce 401s that look like dead keys.
• Coding-plan endpoints. Z.ai runs a separate base URL for its coding subscription tier (/api/coding/paas/v4). Keys work across them but quota is tracked separately.
• Model names are bare (glm-5.1) on the direct API; the z-ai/ prefix is OpenRouter’s namespacing.

If a key 401s on both endpoints, it’s revoked, the dot format makes it obvious which service it belonged to, at least.