Develop
Call the CID222 gateway from your own code — authentication, the chat stream, detection, sessions, files and models.
- Version: 0.4
- Role: admin_user, normal_user
CID222 exposes a REST API. You send chat requests to the gateway instead of to the provider, and the gateway holds the credential, applies your policy to the request and the response, and returns the result. You can also call the detection endpoint on its own, without any model involved, to classify text inside your own pipeline.
Warning
The chat stream is not OpenAI- or Anthropic-shaped. The gateway buffers the model's response,
filters it, and emits the final text as a single event — there are no per-token deltas on the
wire and there is no non-streaming mode. Read
Chat completions before writing a client, and never call
response.json() on /chat/completions.
What this guide contains
- Getting started — what the API is for, a quickstart that works end to end, and how to authenticate.
- API reference — chat completions and the stream contract, sessions, content detection, image analysis, document analysis, and model discovery.
- Guides — best practices, error handling, and worked integration examples.
- SDKs — planned client libraries, and what to use in the meantime.
Two things to know before you start
Route prefixes are not uniform. There is no global API prefix. Chat is at /chat, sessions at
/sessions, models at /models — and content detection is the one surface under
/api/v1/guardrails. Each reference page states its own real path.
Not every surface accepts an API key. A gateway API key (Authorization: Bearer cid_key_…)
works on chat, models and content detection. Sessions, image analysis and document analysis
require a user JWT. Authentication has the full matrix.
Related
- Detection pipeline — what actually happens to your text between the request and the provider.
- Access keys — issuing and revoking the keys your code will use.
Last updated on