Release Notes¶
Version 1.7.1¶
Released: May 22, 2026
Housekeeping: Update SDK to incorporate latest webhook specs; tidy sample toolkits to remove extraneous/unsupported attributes.
Version 1.7.0¶
Released: May 16, 2026
This release adds Toolkit Distribution for automated version propagation across workspaces, Workflow Dry-Run Mode for pre-execution simulation, and several enhancements to the Workflow and Agenda Item APIs.
What's New — Toolkit Distribution
Partners can now automatically propagate published toolkit versions to all connected workspaces, monitor installation status across their workspace fleet, and control auto-install behavior for newly connected workspaces.
- Auto-propagation — When enabled, publishing a new toolkit version automatically upgrades all connected workspaces (respecting opt-outs).
- Force upgrade — Override opt-outs for critical updates using the
propagation: "force"publish parameter. - Installation visibility — Monitor which workspaces have installed, opted out, or never installed a toolkit.
- Auto-install for new workspaces — Automatically install the latest published version when a new workspace connects.
New Admin Endpoints¶
| Method | Endpoint | Description |
|---|---|---|
GET | /v1/partner/admin/toolkits/{id}/installations | List all installations of a toolkit with status summary |
GET | /v1/partner/admin/workspaces | List all workspaces connected to the partner |
Modified Admin Endpoints¶
PATCH /v1/partner/admin/toolkits/{id} — Two new optional fields:
| Field | Type | Description |
|---|---|---|
auto_propagate | boolean | Automatically propagate new versions to connected workspaces on publish |
auto_install_on_new_workspaces | boolean | Automatically install the latest published version when a new workspace connects |
POST /v1/partner/admin/toolkits/{id}/versions/{vid}/publish — New optional propagation field:
| Value | Behavior |
|---|---|
| (omitted) | Use the toolkit's auto_propagate setting |
"none" | Skip propagation regardless of setting |
"normal" | Propagate to active workspaces, respect opt-outs |
"force" | Propagate to all workspaces including opt-outs |
The publish response now includes a propagation object with mode, workspaces_queued, and workspaces_skipped_opted_out counts.
What's New — Workflow Enhancements
- Dry-run mode — Simulate a workflow run without executing side effects. Pass
dry_run: truewhen creating a run to validate the template configuration, role mappings, and readiness checks without actually starting the workflow. - Pre-flight readiness validation — The
POST /v1/partner/user/workflow-runsendpoint now performs configuration validation before starting a run. Issues such as missing Slack configuration, unmapped roles, or invalid input references are returned as structuredreadiness_issuesin the response. - Rejected run status — Workflow runs rejected during human review now surface as
status: "rejected"instead of"failed", giving partners clearer signal about why a run ended. - Action labels — Workflow actions now include an optional
labelfield for display purposes. - Role mappings — Workflow runs now persist
role_mappingsso partners can see which users were assigned to each workflow role.
What's New — Agenda Items
- Talking points — The
POSTandPUTagenda item endpoints now accept an optionaltalking_pointsarray, allowing partners to attach structured discussion points to agenda items.
Additional Improvements¶
- Action button invocation tracking —
POST /v1/partner/user/meetings/{id}/action-buttons/{button_id}/triggernow returns aninvocation_idfor correlating trigger events with downstream processing. - Toolkit provenance — Template responses now include
provenancemetadata (toolkit origin, slug, and version) when the template was created via a toolkit manifest. - Toolkit import conflict detection — Creating a toolkit version now validates the manifest against existing entities. Name/slug conflicts are returned as structured
conflictsin the response, with aforce: trueoption to override.
Version 1.6.0¶
Released: April 17, 2026
This release adds Workflow APIs and Workflow lifecycle webhooks so partners can discover workflow templates, trigger runs programmatically, and receive notifications as runs and tasks progress. It also streamlines the Partner Admin API surface by making Next Steps, Action Buttons, and Shortcuts toolkit-only entities. These "leaf" entities are now created, updated, and deleted exclusively through the Toolkit Manifest — their standalone Admin CRUD endpoints have been removed.
What's New — Workflow APIs
- Admin: List workflow templates —
GET /v1/partner/admin/workflow-templatesreturns all templates scoped to your partner app. - Admin: Get workflow template —
GET /v1/partner/admin/workflow-templates/{id}returns a single template with full definition. - User: Trigger manual workflow run —
POST /v1/partner/user/workflow-runsstarts a manual run for a template in the caller's workspace. - User: List workflow runs —
GET /v1/partner/user/workflow-runslists runs in the caller's workspace. - User: Get workflow run —
GET /v1/partner/user/workflow-runs/{id}returns a single run with current step state.
Workflow run triggers are restricted to trigger_type=manual; autopilot triggers remain reserved for internal use. The User endpoints require new OAuth scopes: partner-api/workflows:read for read operations and partner-api/workflows:write for creating runs. POST /workflow-runs is additionally gated by the Workflow Templates feature entitlement.
New Webhook Events — Workflow Lifecycle
Partners can now receive webhook notifications for workflow runs and tasks:
| Event | Delivered to |
|---|---|
workflow.run.started | Run owner (or manual trigger) |
workflow.run.completed | Run owner |
workflow.run.failed | Run owner |
workflow.step.completed | Run owner |
workflow.task.created | Task assignee |
workflow.task.resolved | Reviewer who recorded the decision |
See the AsyncAPI webhook reference for full payload schemas.
Templates remain available as standalone entities because they have independent value outside the toolkit lifecycle (e.g., browsing, assigning to meetings).
Breaking Change — Removed Admin Endpoints
The following Admin API endpoints have been removed. All leaf entity management now happens through the Toolkit Manifest:
Next Steps (removed):
GET/POST /v1/partner/admin/next-stepsGET/PUT/DELETE /v1/partner/admin/next-steps/{id}
Action Buttons (removed):
GET/POST /v1/partner/admin/action-buttonsGET/PUT/DELETE /v1/partner/admin/action-buttons/{id}
Next Step ↔ Action Button associations (removed):
GET/POST /v1/partner/admin/next-steps/{id}/action-buttonsPUT/DELETE /v1/partner/admin/next-steps/{id}/action-buttons/{ab_id}PUT/DELETE /v1/partner/admin/next-steps/{id}/default-action-button
Migration Path
If you were using standalone endpoints to manage next steps or action buttons:
- Define them in a Toolkit Manifest using the
next_stepsandaction_buttonsarrays - Use
$id/$refcross-references to wire entities together - Create or update the toolkit via
POST /v1/partner/admin/toolkitsorPUT /v1/partner/admin/toolkits/{id}
User API endpoints are unchanged — GET /meetings/{id}/next-steps, /action-buttons, execute, and trigger endpoints continue to work as before.
Version 1.5.0¶
Released: April 3, 2026
This major release introduces Toolkits — a declarative system for defining and deploying complete meeting experiences. Partners can now bundle templates, AI-powered next steps, and action buttons into versioned manifests that install atomically across workspaces.
What's New
- Toolkit Manifests — Declarative JSON format for meeting workflow configuration
- Templates — Meeting structures with customizable next steps
- AI Next Steps — Post-meeting prompts for summaries, follow-ups, and more
- Action Buttons — Delivery mechanisms (email, clipboard, webhook, download)
- SDK 1.5.0 — Full TypeScript support for all new Toolkit APIs
Toolkit Manifest System¶
Define complete meeting experiences in a single JSON document:
{
"templates": [
{
"$id": "sales-call",
"name": "Sales Discovery Call",
"next_steps": [
{ "next_step": { "$ref": "meeting-summary" }, "order": 1 }
]
}
],
"next_steps": [
{
"$id": "meeting-summary",
"name": "Generate Summary",
"type": "ai",
"prompt": "Summarize this sales call including key discussion points.",
"action_buttons": [
{ "action_button": { "$ref": "email-btn" }, "order": 1 }
]
}
],
"action_buttons": [
{
"$id": "email-btn",
"name": "Send via Email",
"delivery_type": "email"
}
]
}
Key Features
- Atomic Installation — All entities install together or not at all
- Reference System — Use
$idand$refto link entities within the manifest - Version Control — Store manifests in your repository and deploy programmatically
- Multi-Workspace — Install the same toolkit across multiple workspaces
See the Toolkit Manifests Guide for complete documentation and examples.
Admin API Endpoints¶
Toolkit Management
| Method | Endpoint | Description |
|---|---|---|
POST | /v1/partner/admin/toolkits | Create a toolkit from manifest |
GET | /v1/partner/admin/toolkits | List all toolkits |
GET | /v1/partner/admin/toolkits/{toolkitId} | Get toolkit details |
PUT | /v1/partner/admin/toolkits/{toolkitId} | Update toolkit manifest |
DELETE | /v1/partner/admin/toolkits/{toolkitId} | Delete toolkit |
GET | /v1/partner/admin/toolkits/{toolkitId}/export | Export single toolkit manifest |
POST | /v1/partner/admin/toolkits/export | Bulk export toolkit manifests |
Toolkit Versioning
| Method | Endpoint | Description |
|---|---|---|
GET | /v1/partner/admin/toolkits/{toolkitId}/versions | List toolkit versions |
POST | /v1/partner/admin/toolkits/{toolkitId}/versions | Create a new version |
GET | /v1/partner/admin/toolkits/{toolkitId}/versions/{versionId} | Get version details |
PATCH | /v1/partner/admin/toolkits/{toolkitId}/versions/{versionId} | Update version metadata |
DELETE | /v1/partner/admin/toolkits/{toolkitId}/versions/{versionId} | Delete a version |
POST | /v1/partner/admin/toolkits/{toolkitId}/versions/{versionId}/publish | Publish a version |
POST | /v1/partner/admin/toolkits/{toolkitId}/versions/{versionId}/republish | Republish a version |
Template Management
| Method | Endpoint | Description |
|---|---|---|
GET | /v1/partner/admin/templates | List templates |
POST | /v1/partner/admin/templates | Create a template |
GET | /v1/partner/admin/templates/{templateId} | Get template details |
PUT | /v1/partner/admin/templates/{templateId} | Update a template |
DELETE | /v1/partner/admin/templates/{templateId} | Delete a template |
GET | /v1/partner/admin/templates/{templateId}/next-steps | List template's next steps |
POST | /v1/partner/admin/templates/{templateId}/next-steps | Associate next step to template |
PUT | /v1/partner/admin/templates/{templateId}/next-steps/{nextStepId} | Update association |
DELETE | /v1/partner/admin/templates/{templateId}/next-steps/{nextStepId} | Remove association |
Next Steps & Action Buttons
As of v1.6.0, standalone Admin CRUD for next steps and action buttons has been removed. Use the Toolkit Manifest to manage these entities. Template↔Next Step association endpoints remain available.
User API Endpoints¶
Toolkits
| Method | Endpoint | Description |
|---|---|---|
GET | /v1/partner/user/toolkits | List available toolkits |
POST | /v1/partner/user/toolkits/{toolkitId}/install | Install toolkit to workspace |
GET | /v1/partner/user/workspaces/{workspace_id}/toolkits | List toolkits installed in workspace |
DELETE | /v1/partner/user/workspaces/{workspace_id}/toolkits/{toolkit_id} | Uninstall toolkit from workspace |
Templates
| Method | Endpoint | Description |
|---|---|---|
GET | /v1/partner/user/meeting-templates | List available templates |
GET | /v1/partner/user/meeting-templates/{id} | Get template details |
POST | /v1/partner/user/meeting-templates/{id}/apply | Apply template to a meeting |
GET | /v1/partner/user/meeting-templates/{id}/next-steps | List template's next steps |
Meeting Next Steps & Action Buttons
| Method | Endpoint | Description |
|---|---|---|
GET | /v1/partner/user/meetings/{id}/next-steps | Get meeting next steps |
POST | /v1/partner/user/meetings/{id}/next-steps/{next_step_id}/execute | Execute a next step |
GET | /v1/partner/user/next-step-results/{result_id} | Get next step execution result |
GET | /v1/partner/user/meetings/{id}/action-buttons | Get meeting action buttons |
POST | /v1/partner/user/meetings/{id}/action-buttons/{button_id}/trigger | Trigger action button |
SDK Examples¶
Create and Install a Toolkit
import { ContioPartnerSDK } from '@contio/partner-sdk';
const sdk = ContioPartnerSDK.forAdmin({ apiKey: process.env.API_KEY });
// Create toolkit from manifest
const toolkit = await sdk.admin.createToolkit({
name: 'Sales Workflow',
description: 'Post-meeting follow-up automation',
manifest: salesManifest
});
// Install on a workspace
await sdk.admin.installToolkit(toolkit.id, {
workspace_id: 'ws_abc123'
});
Execute Meeting Next Steps
const userSdk = ContioPartnerSDK.forUser({
clientId: process.env.CLIENT_ID,
clientSecret: process.env.CLIENT_SECRET,
redirectUri: 'https://your-app.com/callback'
});
// Get next steps for a meeting
const nextSteps = await userSdk.user.getMeetingNextSteps(meetingId);
// Execute AI-powered next step
const execution = await userSdk.user.executeNextStep(meetingId, nextStepId);
// Poll for result
const result = await userSdk.user.getNextStepResult(meetingId, nextStepId);
console.log(result.output); // AI-generated content
OAuth Scopes¶
New scopes for Toolkit access:
| Scope | Description |
|---|---|
toolkits:read | Read toolkit and template information |
toolkits:write | Install/uninstall toolkits |
next_steps:execute | Execute meeting next steps |
action_buttons:trigger | Trigger action buttons |
New Webhook Events¶
Three new webhook events support the Toolkit system:
| Event | Description |
|---|---|
meeting_template.applied | Sent when a meeting template is applied to a meeting |
next_step.completed | Sent when a Next Step execution completes (AI or redirect) |
action_button.triggered | Sent when a partner's action button is triggered |
Example: next_step.completed Payload
{
"event_type": "next_step.completed",
"event_id": "evt-550e8400-e29b-41d4-a716-446655440000",
"timestamp": "2026-04-01T10:30:00Z",
"partner_app_id": "app-550e8400-e29b-41d4-a716-446655440000",
"for_user": {
"id": "user-550e8400-e29b-41d4-a716-446655440000",
"email": "user@example.com"
},
"data": {
"next_step_id": "ns-550e8400-e29b-41d4-a716-446655440000",
"next_step_name": "Generate Meeting Summary",
"meeting_id": "mtg-550e8400-e29b-41d4-a716-446655440001",
"result_id": "nsr-550e8400-e29b-41d4-a716-446655440003",
"executed_by": "user-550e8400-e29b-41d4-a716-446655440004",
"executed_at": "2026-04-01T10:30:00Z",
"execution_mode": "manual"
}
}
See the Webhook Events Reference for complete payload schemas.
Version 1.4.7¶
Released: March 20, 2026
This release introduces the Chat Session API, enabling partners to programmatically interact with the Contio AI agent through asynchronous, turn-based conversations. Sessions can optionally be scoped to meetings and primed with context documents for targeted AI assistance.
Chat Session Endpoints¶
| Method | Endpoint | Description |
|---|---|---|
POST | /v1/partner/user/sessions | Create a new chat session with an initial message |
GET | /v1/partner/user/sessions | List chat sessions (filterable by meeting) |
GET | /v1/partner/user/sessions/{id} | Get session details with paginated turns |
PUT | /v1/partner/user/sessions/{id} | Send a follow-up message to an existing session |
Key Features¶
- Turn-based conversations — Each session tracks user and agent messages as ordered turns with 0-based sequence numbering
- Meeting-scoped sessions — Optionally associate a session with a meeting so the AI agent has full meeting context
- Context document priming — Attach context documents (uploaded via the Meeting Context API) to give the agent additional reference material
- Partner metadata — Attach up to 10 key-value pairs to sessions for your own tracking purposes
- Idempotent creation — Use the
Idempotency-Keyheader to safely retry session creation without duplicates - Turn pagination — Retrieve session turns with configurable
turn_limitandturn_offsetparameters - Agent metadata — Agent turns include tool call details, referenced documents, and token usage statistics
OAuth Scopes¶
- New
chat:readscope grants read access to sessions and turns (list, get) - New
chat:writescope grants write access (create sessions, send messages) and implicitly includeschat:readcapability
Limits¶
| Limit | Value |
|---|---|
| Message length | 10,000 characters |
| Metadata keys per session | 10 |
| Metadata key length | 256 characters |
| Metadata value length | 1,024 characters |
| Turns per session | 100 |
| Default turn page size | 50 (max 200) |
Version 1.4.6¶
Released: March 13, 2026
This release introduces the Meeting Context API, enabling partners to upload, retrieve, and manage supplemental context documents for meetings. Context documents are preprocessed for use during AI-powered meeting summarization and action item extraction.
Meeting Context Endpoints¶
POST /v1/partner/user/meetings/{id}/context— Upload a context document for a meetingGET /v1/partner/user/meetings/{id}/context— List all context documents for a meetingGET /v1/partner/user/meetings/{id}/context/{context_id}— Get a specific context documentGET /v1/partner/user/meetings/{id}/context/{context_id}/content— Download context document contentDELETE /v1/partner/user/meetings/{id}/context/{context_id}— Delete a context document
OAuth Scopes¶
- New
context:readandcontext:writescopes control access to Meeting Context endpoints - These scopes are independent of the existing
meetings:readandmeetings:writescopes
Version 1.4.5¶
Released: March 06, 2026
This release adds webhook management capabilities: automatic webhook disabling on repeated delivery failures, manual webhook status control, and event filtering with include/exclude modes.
Webhook Auto-Disable¶
- Webhooks are automatically disabled after 50 consecutive abandoned deliveries or 72 hours without a successful delivery
- Partners are notified via email when auto-disable triggers
- New deliveries are recorded as
pendingwhile disabled, preserving events for later delivery - Feature-flagged via
webhook_auto_disable
Webhook Status Management¶
PUT /v1/partner/admin/webhook-status— Enable or disable webhooks manuallypending_dispositionoption: choosedeliver(retry pending events) orabandon(discard pending events) when re-enabling- SDK:
admin.updateWebhookStatus({ enabled: true/false })
Webhook Event Filtering¶
PUT /v1/partner/admin/webhook-filter— Set include or exclude filter for event typesDELETE /v1/partner/admin/webhook-filter— Remove filter (receive all events)- 15 filterable event types;
user.connection.revokedalways bypasses filters - SDK:
admin.setWebhookFilter({ ... })andadmin.removeWebhookFilter()
Version 1.4.3¶
Released: February 27, 2026
This backward-compatible release adds shared workspace support to the Partner OAuth connect flow, allowing partners to provision multiple users into the same workspace.
Shared Workspace Provisioning¶
- The
POST /auth/initiateendpoint now accepts optionalworkspace_idandis_adminfields. Whenworkspace_idis provided, the new user is added to the specified existing workspace instead of creating a personal workspace. is_admin: trueassigns theWORKSPACE_ADMINrole;is_admin: false(default) assignsWORKSPACE_MEMBER.- New validation error codes:
workspace_not_found(404),workspace_not_authorized(403),workspace_conflict(409). - The 409 conflict response includes the user's current
workspace_idas a dedicated field for programmatic reconciliation.
Profile Enhancement¶
- The
GET /v1/partner/user/profileendpoint now returnsworkspace_id,workspace_name, andworkspace_rolefields.
Version 1.4.2¶
Released: February 17, 2026
This backward-compatible release standardizes the date search query parameters and error responses across all Partner API endpoints.
- The "start_date" and "end_date" query parameters are now fully supported for meetings and action items search endpoints.
- The calendar search endpoint now also expects "start_date" and "end_date" query parameters for consistency. The "start" and "end" query parameters have been deprecated and will be removed in a future version.
- Error responses have been standardized for all endpoints. The "error" and "request_id" fields are now utilized consistently, and the "message" field has been deprecated.
- API documentation has been updated to reflect these improvements and deprecations.
Version 1.4.0¶
Released: January 31, 2026
This release adds calendar event details retrieval and comprehensive webhook events for meeting updates, calendar sync, and agenda item lifecycle tracking.
What's New
- 1 new API endpoint for retrieving calendar event details
- 7 new webhook events for meeting updates, calendar events, and agenda items
Calendar Event Details¶
Retrieve full details of a specific calendar event by ID.
New Endpoint
| Method | Endpoint | Description |
|---|---|---|
GET | /v1/partner/user/calendar/events/{calendar_event_id} | Get calendar event details |
Key Features
- Retrieve complete calendar event information including title, times, and attendees
- Access organizer details and attendee list with response status
- Supports both timed and all-day events
Example Usage
// Get calendar event details
const event = await sdk.user.getCalendarEvent(calendarEventId);
console.log(event.title); // "Product Planning Meeting"
console.log(event.start_time); // "2026-01-31T10:00:00Z"
console.log(event.attendee_count); // 5
New Webhook Events¶
Seven new webhook events provide real-time notifications for meeting updates, calendar sync, and agenda item lifecycle.
Meeting Events
| Event | Description |
|---|---|
meeting.updated | Meeting title, scheduled time, or other properties changed |
Calendar Events
| Event | Description |
|---|---|
calendar_event.created | Calendar event synced from external calendar (Google, Outlook) |
calendar_event.updated | Calendar event updated in external calendar |
calendar_event.deleted | Calendar event cancelled/deleted in external calendar |
Agenda Item Events
| Event | Description |
|---|---|
agenda_item.created | Agenda item created in a meeting or backlog |
agenda_item.updated | Agenda item title, status, or properties changed |
agenda_item.deleted | Agenda item removed from meeting or backlog |
Event Delivery
- Calendar events are delivered to the user whose calendar was synced
- Agenda item events for meeting items are delivered to all meeting participants; for backlog items, only to the creator/updater
See the Webhook Events Guide for complete event schemas and examples.
Version 1.3.0¶
Released: January 21, 2026
This release significantly expands the Partner User API with comprehensive meeting collaboration capabilities. Partners can now manage meeting participants, agenda items, and calendar integrations, enabling deeper integration with MeetingOS workflows.
What's New
- 11 new API endpoints for participants, agenda items, and calendar integration
- 6 new webhook events for real-time meeting and action item notifications
- Consolidated API documentation with improved organization
Meeting Participant Management¶
Programmatically manage meeting participants through the Partner User API.
New Endpoints
| Method | Endpoint | Description |
|---|---|---|
GET | /v1/partner/user/meetings/{id}/participants | List meeting participants |
POST | /v1/partner/user/meetings/{id}/participants | Add a participant |
DELETE | /v1/partner/user/meetings/{id}/participants/{participant_id} | Remove a participant |
Key Features
- Add participants by email (supports both registered users and guests)
- Assign participant roles:
EDITORorVIEWER - Automatic guest provisioning when adding new participants
- View all participants with roles and metadata
Example Usage
// List participants
const participants = await sdk.user.getMeetingParticipants(meetingId);
// Add a participant
await sdk.user.addMeetingParticipant(meetingId, {
email: 'john.doe@example.com',
name: 'John Doe',
role: 'EDITOR'
});
// Remove a participant
await sdk.user.removeMeetingParticipant(meetingId, participantId);
Agenda Item Management¶
Create, update, and delete agenda items within meetings.
New Endpoints
| Method | Endpoint | Description |
|---|---|---|
GET | /v1/partner/user/meetings/{id}/agenda-items | List agenda items |
POST | /v1/partner/user/meetings/{id}/agenda-items | Create an agenda item |
PUT | /v1/partner/user/meetings/{id}/agenda-items/{item_id} | Update an agenda item |
DELETE | /v1/partner/user/meetings/{id}/agenda-items/{item_id} | Delete an agenda item |
Key Features
- Create structured agenda items with titles, descriptions, and time allocations
- Support for multiple item types:
DISCUSSION,DECISION,UPDATE, etc. - Automatic synchronization with Tiptap collaborative editor
- Update or delete agenda items as needed
Example Usage
// Create an agenda item
const newItem = await sdk.user.createAgendaItem(meetingId, {
item_type: 'DISCUSSION',
title: 'Q4 Budget Review',
description: 'Review and approve Q4 budget allocation',
time_allocation_minutes: 15
});
// Update an agenda item
await sdk.user.updateAgendaItem(meetingId, itemId, {
title: 'Updated Title',
time_allocation_minutes: 20
});
Calendar Integration¶
Access user calendar events and link them to meetings.
New Endpoints
| Method | Endpoint | Description |
|---|---|---|
GET | /v1/partner/user/calendar/events | List calendar events |
POST | /v1/partner/user/meetings/{id}/calendar/link | Link a calendar event |
DELETE | /v1/partner/user/meetings/{id}/calendar/unlink | Unlink a calendar event |
POST | /v1/partner/user/calendar/events/{id}/meeting | Create meeting from event |
Key Features
- Query calendar events with date range filtering
- Link existing calendar events to MeetingOS meetings
- Create meetings automatically from calendar events
- Access calendar event metadata (attendees, location, times)
Example Usage
// Get calendar events
const events = await sdk.user.getCalendarEvents({
start: '2026-01-01T00:00:00Z',
end: '2026-01-31T23:59:59Z',
limit: 50
});
// Create meeting from calendar event
const result = await sdk.user.createMeetingFromCalendarEvent({
calendar_event_id: calendarEventId
});
Enhanced Webhook Events¶
Six new webhook events provide real-time notifications for meeting and action item lifecycle.
New Events
| Event | Description |
|---|---|
meeting.created | New meeting created |
meeting.completed | Meeting processing complete |
action_item.created | New action item created |
action_item.completed | Action item marked complete |
participant.added | Participant(s) added to meeting |
participant.removed | Participant removed from meeting |
Multi-User Delivery
Participant events (participant.added, participant.removed) are delivered to all partner apps connected to users who are participants in the meeting, enabling collaborative workflows.
See the Webhook Events Guide for complete event schemas and examples.
Version 1.2.1¶
Released: January 17, 2026
Minor improvements to OAuth and webhook handling.
Changes
- Added
login_hintparameter support ingetAuthorizationUrl() - Added support for
id_tokenintrospection and verification - New Express middleware for webhook signature verification
Version 1.2.0¶
Released: January 8, 2026
This release introduces a new opaque token format for improved security and privacy.
Opaque Token Format¶
Access and refresh tokens now use a consistent, versioned format that abstracts internal implementation details.
What's New
- New Token Format - Access tokens:
cto_at_v1_..., Refresh tokens:cto_rt_v1_... - Improved Security - Tokens no longer expose internal claims or metadata
- Version Routing - Token version prefix enables seamless future upgrades
Backward Compatibility
- Existing JWT-format tokens continue to work during the transition period
- Legacy tokens show a deprecation warning header (
X-Contio-Token-Deprecated) - No code changes required - the SDK handles both token formats automatically
Migration Notes
If you're storing or parsing tokens directly (not recommended):
- Do not parse token contents - Opaque tokens contain no readable claims
- Use introspection - Call
oauth.introspectToken()to get token metadata - Update token validation - If you validate tokens locally, switch to introspection
See the Token Migration Guide for details.
Version 1.1.0¶
Released: January 2, 2026
This release introduces Partner IdP SSO, enabling your users to sign in to Contio using your corporate identity provider.
Single Sign-On (SSO) Integration¶
New Features
- SSO Integration Guide - Step-by-step guide for configuring your OIDC-compliant identity provider
- User Provisioning Guide - Documentation explaining automatic user provisioning during OAuth
- SDK SSO Methods - New
getIdpLoginUrl()andgetSsoStatusUrl()methods
How It Works
- Users connect to Contio via OAuth (establishing consent and provisioning)
- Configure your identity provider in the Partner Dashboard
- Users can then sign in using your corporate credentials via SSO
Info
SSO provides authentication convenience for returning users who have already connected via OAuth. See the SSO Integration Guide for complete setup instructions.
Version 1.0.1¶
Released: December 16, 2025
Documentation improvements and new documentation site launch.
Changes
Launched official documentation site at docs.contio.ai/partner-api
- Slimmed down SDK README to essentials with links to full documentation
- Removed bundled
docs/folder from SDK distribution (now served from docs site) - Added comprehensive guides: OAuth Flow, Credential Management, Troubleshooting
- Added detailed API reference with code examples
Version 1.0.0¶
Released: November 15, 2025
Initial release of the Contio Partner SDK.
Features
OAuth 2.0 authentication with PKCE support
Meeting data access (summaries, notes, transcripts)
Action item management
Webhook event handling with signature verification
TypeScript support with full type definitions