Release Notes¶

Version 1.1.0 — Idempotency-Key Support¶

Released: July 27, 2026

POST mutations on the /v1 User API now support safe retries with an Idempotency-Key header. If a request is interrupted or retried, sending the same key with the same request body replays the original 2xx response instead of executing the operation a second time.

What's new

Idempotency-Key header on POST endpoints for meetings, action items, agenda items, meeting participants, and webhook re-enable.
Idempotent-Replayed response header (true) present when a request is served from the idempotency cache.
Standard error codes for idempotency conflicts: idempotency_conflict (409 + Retry-After), idempotency_key_reuse (422), and idempotency_key_invalid (400).
No breaking changes — omitting the header preserves the existing behavior.

Using Idempotency-Key¶

Include a client-generated, opaque key in the Idempotency-Key header:

curl -X POST https://api.contio.ai/v1/meetings \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Idempotency-Key: $(uuidgen)" \
  -H "Content-Type: application/json" \
  -d '{"title":"Weekly Sync","detail_level":"STANDARD"}'

If the connection drops before you receive the response, retry the exact same request with the same Idempotency-Key. The second call returns the original 201 response and includes Idempotent-Replayed: true.

Key requirements

The key must be printable ASCII and no longer than 255 characters.
Reusing a key with a different request body returns 422 idempotency_key_reuse.
Keys are scoped to your credential; a user PAT and a workspace API key can each use the same key independently.

See the Errors guide for retry and idempotency conventions.

Version 1.0.0 — `/v1` General Availability¶

Released: July 2026

The Contio MeetingOS User API (/v1) is now generally available. This is the first-party REST API that lets you build on top of your own workspace — managing meetings, agenda items, action items, calendars, workspace settings, and webhooks — authenticated as yourself.

What's in GA

First-party OAuth 2.1 + PKCE authorization-code flow with a system-browser + loopback redirect, rotating refresh tokens, RFC 7009 revocation, and an RFC 8414 OIDC discovery document (hyphenated .well-known/openid-configuration).
Personal Access Tokens (PATs) you can self-issue for automation, scoped to a subset of your own grants, with selectable expiry.
Meetings, agenda items, action items, calendar, and workspace resource endpoints.
Workspace administration: members, API keys, and webhooks (including re-enable and secret rotation).
Real-time delivery: signed workspace webhooks and a resumable Server-Sent Events stream.
Documented API conventions: rate limits, a standard error envelope, and pagination.
A generated OpenAPI 2.0 reference that is the source of truth for the API surface.

Authentication¶

OAuth 2.1 + PKCE (S256 only): GET /v1/oauth/authorize, POST /v1/oauth/token (authorization_code and refresh_token grants), POST /v1/oauth/revoke.
- Loopback redirect URIs (http://127.0.0.1:PORT / http://localhost:PORT) for native apps and CLIs. No client secret (token_endpoint_auth_methods_supported: ["none"]).
- Refresh tokens rotate on every use.
- Discovery: GET /v1/oauth/.well-known/openid-configuration and GET /v1/oauth/.well-known/jwks.json.
Personal Access Tokens: POST /v1/user/tokens (name, scopes ⊆ your grants, expiry_days ∈ {30, 60, 90, 180, 365}; plaintext returned once), GET /v1/user/tokens, DELETE /v1/user/tokens/{id}.
Tokens are opaque and versioned: access cto_at_v1_, refresh cto_rt_v1_, PAT cto_pat_v1_.

Scopes¶

Several scopes gate the API, for example: meetings:read, meetings:write, workspace:read, workspace:write. See API Scopes for a full listing.

Resource endpoints¶

Area	Endpoints
Meetings	`GET/POST /v1/meetings`, `GET/DELETE /v1/meetings/{id}`, participants, and context
Agenda items	`GET/POST /v1/agenda-items`, `PATCH/DELETE /v1/agenda-items/{id}`
Action items	`GET/POST /v1/action-items`, `PATCH/DELETE /v1/action-items/{id}`
Calendar	`GET /v1/calendar/events`, `GET /v1/calendar/events/{id}`
Workspace	`GET/PATCH /v1/workspace`, members, API keys, and webhooks
Events	`GET /v1/user/events` (Server-Sent Events stream, resumable via `Last-Event-ID`)

See the API Reference for the full catalog and the interactive OpenAPI reference for authoritative schemas.

Documentation¶

Getting started:

Getting Started — pick a credential and make your first request.
Authentication guide — the OAuth 2.1 + PKCE loopback flow, refresh rotation, and revocation, with a full Python loopback example.
Personal Access Tokens guide — issuing, listing, and deleting PATs.

Real-time & automation:

Workspace Webhooks — HMAC-SHA256 signed deliveries, signature verification in three languages, and replay protection.
User Events (SSE) — consuming the resumable event stream.
Agent Integration — machine-readable artifacts for building agents against the API.

API conventions:

Rate Limits — per-plan request budgets and the X-RateLimit-* headers.
Errors — the standard error envelope, retry/idempotency guidance, and timestamp conventions.
Pagination — the limit/offset convention and list-response envelope.

Generated, not hand-maintained

The OpenAPI reference on this site is generated from the /v1 controllers via task api:gen-user-openapi. A CI drift check keeps the committed spec in lockstep with the code.