Make your first AI API request with a key, model ID and cURL

Collect four pieces of configuration

Use key management (Chinese interface) to create or select an API key. Name it for the application and select an allowed group; configure limits or expiry as appropriate. Confirm the exact model identifier, base URL and protocol. A key does not make every catalog model available.

Use a protocol-specific template

This cURL example uses POSIX shell syntax. Set YOUJIE_BASE_URL and YOUJIE_API_KEY locally, then replace YOUR_ENABLED_MODEL with an allowed identifier. The integration guide provides additional context.

curl "$YOUJIE_BASE_URL/chat/completions" \
  -H "Authorization: Bearer $YOUJIE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"YOUR_ENABLED_MODEL","messages":[{"role":"user","content":"Explain tokens in one sentence."}]}'

The base URL usually already ends in /v1. Do not append /v1 twice. Messages and native Gemini APIs use different request shapes.

Check what happened

Inspect HTTP status, actual response content and the usage record. Begin with a short non-sensitive prompt. Add streaming or tools only after confirming support. This guide reviews the template and implementation; it does not include a paid request or a fabricated success response.

Diagnose status codes

For 401/403, check credentials, account status, group permission and model access. For 400/404, inspect JSON, spelling, protocol paths and duplicated prefixes. For 429, inspect quota, concurrency and rate limits; it does not always mean insufficient balance. Use the error message to identify the cause.

Maintain separate keys

Name keys by application and avoid exposing them in screenshots, chat or repositories. Revoke compromised keys and update clients. Use the usage review guide to investigate changes. Account credit, subscription benefits and key-level limits are separate controls.

Use a known-answer acceptance target

Reviewed model detail pages now include a request asking for a JSON object whose total is the sum of 17 and 25. This deliberately small target separates several checks: did the HTTP call succeed, did the response match the selected protocol, did the final content parse as JSON, and was the answer correct?

For a non-streaming Chat Completions response saved locally as response.json, the following Node.js check uses the final answer rather than reasoning text. Run it in a local script, not in a public webpage.

import { readFileSync } from 'node:fs';
const response = JSON.parse(readFileSync('response.json', 'utf8'));
const content = response.choices?.[0]?.message?.content;
if (typeof content !== 'string') throw new Error('Missing final text');
const result = JSON.parse(content);
if (result.total !== 42) throw new Error('Acceptance target failed');
console.log('Answer accepted; inspect actual usage and billing separately.');

This strict check rejects extra Markdown fences rather than silently repairing them. It does not test tool calling, streaming, model identity or broad intelligence. The expected value 42 is a mathematical target, not a claimed provider response. Review Astra’s template or Kimi K3’s integration constraints, then record real usage if you choose to send a paid request.