API endpoint and capability matrix

Beginner: path, model, and channel are separate

A path selects a request contract, a model ID selects a capability, and a channel selects the upstream destination. All three must match. Start in the model marketplace, find the exact ID and its enabled endpoints, then choose a route below. A provider offering image models does not mean every image model works through a chat endpoint.

Minimal discovery request

Use the same site token planned for production. Presence in this response still does not prove support on every endpoint, so follow it with one inexpensive contract request.

Copycurl "$BASE_URL/v1/models"   -H "Authorization: Bearer $API_KEY"

Registered but unsupported

/v1/files, /v1/images/variations, and legacy fine-tunes routes currently return not implemented. Registration provides a deterministic error; it is not a capability promise. Documentation must distinguish an HTTP route, an upstream feature, and a gateway channel adaptation.

Intermediate verification

Record path, exact model, Request-ID, HTTP status, response object type, and usage. For 404, check spelling, token visibility, and endpoint adaptation. For 400, validate the schema. For 401 or 403, inspect the site token. For 429, distinguish request rate, token throughput, quota, and balance.

Expert contract

Maintain an allowlist rather than concatenating arbitrary paths. For every capability, record method, content type, sync or async behavior, streaming, terminal states, body limits, result retention, retryable errors, and billing unit. Run a contract test against the real model whenever a channel or protocol changes; replacing only the base URL is never sufficient.