First client request

Use this path after the gateway is healthy and at least one provider account is enabled. It proves the client-facing boundary: base URL, bearer key, model selection, and the receipt left in usage history.

What you need

• A ready gateway Confirm /ready returns successfully before configuring a client.
• A client key Use the shared proxy_api_key or a managed key with access to the provider/account target it may call. Custom aliases are authorized through their concrete targets, not through alias-specific key scopes.
• An enabled model Ask the gateway for its catalog instead of guessing a provider model name.

Read the catalog first

export IO_GATEWAY_URL=http://127.0.0.1:8319
export IO_GATEWAY_KEY='replace-with-your-client-key'

curl -sS "$IO_GATEWAY_URL/v1/models" \
  -H "Authorization: Bearer $IO_GATEWAY_KEY"

Choose a model returned by /v1/models. For a managed key, the catalog is filtered to its permitted provider/account routes. A model name can select a provider naturally, a three-letter prefix can force one, and a ctm: alias can apply a route policy you created.

Send one response

curl -sS "$IO_GATEWAY_URL/v1/responses" \
  -H "Authorization: Bearer $IO_GATEWAY_KEY" \
  -H "Content-Type: application/json" \
  --data '{
    "model": "gpt-5.2",
    "input": "Reply with one short line."
  }'

Replace gpt-5.2 with a model from your own catalog. The Responses API is the primary OpenAI-compatible route; existing OpenAI Chat Completions clients can use POST /v1/chat/completions, and Anthropic clients can use POST /claude/v1/messages.

Read the receipt

1. 1
   Confirm the client response.

   A successful response proves the request cleared client authentication and reached an eligible route.

2. 2
   Check usage history.

   Confirm the selected provider and account match the route policy you expected.

3. 3
   Repeat with a managed key.

   Use the real key your client will receive to prove its provider/account scope, per-request input cap, and input-token budget behave as intended.