Requests and responses
Use /api/v1 after your server origin. JSON request field names use the spellings shown in the schema. Path and query parameter names are shown individually on operation pages.
Request bodies
Section titled “Request bodies”For JSON requests, send Content-Type: application/json. A discriminator such as kind or type selects one of the schema’s variants. Use the matching fields for that variant.
Binary enrollment and upload operations declare their own media types. Identity import inspection and preview use multipart fields, including a package and passphrase. Their request templates use --form so cURL supplies the multipart boundary.
Responses
Section titled “Responses”Success responses can be JSON objects, arrays, page objects, image bytes, video, CSV, or empty bodies. Select a parser using the response status and Content-Type. A 204 response has an empty body. 202 usually signals accepted or pending work. Snapshot 304 reuses your cached image.
Binary reference templates save the response as response.bin and headers as response-headers.txt. Check the status before treating the saved bytes as an image or video.
Schema details
Section titled “Schema details”Browse request and response models. Each model includes field types, required fields, defaults, constraints, and its complete contract JSON schema. Cross-field runtime checks can impose additional requirements beyond the schema.
The shared runtime error handler adds instance to problem responses. The contract’s ProblemResponse model currently lists the core fields without instance. Parse error metadata according to Errors and status codes.
Conditional and contextual headers
Section titled “Conditional and contextual headers”| Header | Purpose |
|---|---|
If-Match |
Current revision or version required for a protected write. |
Idempotency-Key |
Stable identifier for a logical request when the operation supports it. |
If-None-Match |
Cached snapshot ETag for a conditional read. |
Retry-After |
Server-provided delay before a subsequent request. |
X-EyesOnIt-Session-Id |
Expected user-session identity for workspace consistency. |
X-CSRF-Token |
CSRF protection for cookie-authenticated writes. |
Use headers only where the operation documents them. The meaning of a revision or key belongs to that particular resource.