Skip to content

Release Notes

Version 1.3.0 — Backlog Items & Meeting Attachments

Released: August 10, 2026

The User API now exposes a workspace backlog for agenda items that are not currently attached to a meeting, and adds full Meeting Attachment management on a meeting. Backlog items can be created directly, updated, deleted, moved onto a meeting agenda, and listed with their history. Attachments are raw files that are stored exactly as uploaded and are not PII-scrubbed; use the existing Meeting Context endpoints for material the Contio AI agent should read.

What's new

  • Backlog item CRUD: GET / POST /v1/backlog-items, GET / PATCH / DELETE /v1/backlog-items/{id}.
  • Assign to a meeting: POST /v1/backlog-items/{id}/assign creates a new agenda item on the destination meeting and closes the backlog item.
  • Backlog history: GET /v1/backlog-items/history returns items that were assigned or removed, including assigned_at, destination_meeting_id, and deleted_at.
  • Meeting Attachment management: GET / POST /v1/meetings/{id}/attachments, GET / DELETE /v1/meetings/{id}/attachments/{attachment_id}, and GET /v1/meetings/{id}/attachments/{attachment_id}/download.
  • No breaking changes — the new endpoints use existing meetings:read and meetings:write scopes.

Version 1.2.0 — Dynamic Client Registration & Third-Party MCP OAuth

Released: August 3, 2026

The User API and hosted MCP gateway now support Dynamic Client Registration (RFC 7591) for third-party clients. MCP clients such as Claude Desktop, Cursor, and other third-party agents can self-register at runtime, complete an OAuth 2.1 + PKCE authorization-code flow with a browser-based consent screen, and obtain cto_at_v1_ / cto_rt_v1_ tokens without a pre-provisioned client ID or PAT.

What's new

  • Dynamic Client Registration with POST /v1/oauth/register and management endpoints at GET / PUT / DELETE /v1/oauth/register/{client_id} using the registration_access_token.
  • Third-party OAuth 2.1 + PKCE with an explicit user-consent screen; OAuth endpoint URLs are advertised in the /.well-known/oauth-authorization-server discovery document.
  • Custom redirect-URI support for https:// callbacks, loopback http:// URIs, and Contio desktop deep links such as contio://app/auth/callback (plus environment variants).
  • Hosted MCP gateway discovery now advertises the registration_endpoint at https://mcp.contio.ai/.well-known/oauth-authorization-server so MCP clients can discover and run the DCR flow.
  • No breaking changes — existing first-party OAuth, PAT, SLT, and workspace API key flows continue to work unchanged.

Using DCR with the hosted MCP gateway

  1. Point your MCP client at https://mcp.contio.ai/mcp.
  2. Read https://mcp.contio.ai/.well-known/oauth-authorization-server to discover registration_endpoint, authorization_endpoint, token_endpoint, etc.
  3. Register the client by POSTing to the discovered registration_endpoint.
  4. Open the discovered authorization_endpoint in a browser with PKCE S256 and have the user approve the consent screen.
  5. Capture the returned code from the redirect and exchange it at the discovered token_endpoint.

See the Hosted MCP Server guide for the full DCR payload, supported scopes, and redirect-URI rules.

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:

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.