Create a narrow access boundary
Create an account and API key through the xAI console, then keep the key in a server-side environment variable named XAI_API_KEY. A browser bundle, public repository, screenshot, or copied request log is not a safe place for a credential.
Use a separate key for each environment and team boundary. That makes rotation, spend review, and incident response specific instead of destructive.
- Never prefix a public client variable with a secret key.
- Commit an empty .env.example, never the populated file.
- Rotate a key immediately if it appears in a build artifact or log.
Send one observable request
The official quickstart demonstrates the Responses endpoint. Select a currently available text model from the live model directory, send a small input, and inspect the returned text and usage before adding framework abstractions.
Keep the model identifier in configuration. The stable architectural choice is the request contract; the best model name can change.
curl https://api.x.ai/v1/responses \
-H "Authorization: Bearer $XAI_API_KEY" \
-H "Content-Type: application/json" \
-d '{"model":"MODEL_ID_FROM_MODELS_PAGE","input":"Return one concise system check."}'Harden the path before expanding it
Add an explicit timeout, bounded retries for transient failures, structured error handling, and request correlation before building a large prompt layer. Record latency and usage metadata without recording secrets or sensitive prompt content.
Your first acceptance test should prove both success and failure: a valid request returns usable text, while a missing key or invalid request produces a controlled message rather than a blank screen.