Krisp Portal API

The Krisp Portal API is a REST API that lets you programmatically manage your Krisp team. It is intended for admins managing large deployments where automating seat management, user provisioning, and usage monitoring would reduce manual overhead.

The API works for both device-based and email-based teams. The team type is determined by the API key you generate. No additional configuration is required.

Team management endpoints are on v2. The v1 seat, invite, and device endpoints are deprecated: see Migrating from v1 for the replacement paths. Analytics, Speech Analytics, and Audit Logs endpoints remain on v1 and are unaffected.

Full endpoint reference and example requests are available in the Krisp Portal API Postman documentation.

Get your API key and secret

API credentials are generated per team in the Admin Portal. You need both the API key name and the secret to authenticate requests.

1. In the Admin Portal, go to Integrations >>> API.

2. Click on Create new key. A panel opens on the right.

   

3. Enter a name for the key in the Name of the key field, then click Create.

   

4. Copy both the API key name and the Secret key and store them securely. The secret is only shown once and cannot be retrieved after you close this panel.

   

Rename or delete a key

To rename or delete an existing key, click on it in the API list. The edit panel opens on the right, where you can update the name or permanently delete the key.

Authentication

The API uses HTTP Basic authentication. All requests must include an Authorization header with a Base64-encoded string of your API key name and secret, separated by a colon.

Header format:

Authorization: Basic base64(<api_key>:<secret>)

All requests must be made over HTTPS. Requests over plain HTTP and unauthenticated requests will fail.

Base URL:

https://teams.krisp.ai

Available endpoints

Endpoints are grouped into five functional areas: seat management, user and device management, Analytics, Speech Analytics, and Audit Logs. The API key you use determines which team type (device or email) the operations apply to.

Seat management

These endpoints are available for both device-based and email-based teams.

Filtering, sorting, and pagination

GET /api/v2/seats accepts the following query parameters.

Example request:

GET /api/v2/seats?page=1&perPage=50&orderKey=email&order=asc&filter={"role":"admin","status":"logged_in"}

The filter value must be URL-encoded. If it cannot be parsed as JSON, or if a key is unknown or its value is invalid, the request returns an error.

User and device management

The endpoints available depend on the team type associated with the API key. Device teams are only supported on Windows.

Analytics

These endpoints are available for both team types.

Speech Analytics

These endpoints are available for both team types and require no additional configuration.

Audit Logs

This endpoint is available for both team types and requires no additional configuration.

Migrating from v1

The v1 seat, invite, and device endpoints have been replaced by their v2 equivalents. The paths and parameters map one to one, so in most cases updating your integration means changing /api/v1/ to /api/v2/ in the request URL.

Three changes go beyond the path. Review these before switching over:

• Seat filtering changed. In v1, seats were filtered with individual query parameters. In v2, filters are passed as a single URL-encoded JSON object in the filter parameter, and order and orderKey are available for sorting.
• The seat object has new fields. last_activity, has_app_access, and email are returned alongside the existing fields. Existing fields are unchanged.
• Unassigning a seat accepts a retention policy. The data body parameter controls whether the user's data is kept or deleted. If you omit it, the behavior matches v1.

Rate limiting

Rate limiting is applied per IP address. If the request threshold is exceeded, all requests from that IP are blocked for a set period and the API returns HTTP 429. The default configuration is 700 requests per minute, with a 1-hour blocking period.

Response codes

Error codes

When a request fails, the response body includes an error_code field with additional context on why the request failed.

Versioning

The API version is included in the URL path (e.g., /api/v2/). Seat, invite, and device endpoints are currently on v2. Analytics, Speech Analytics, and Audit Logs endpoints are on v1.

A new version is published only for breaking changes: changes to response attribute names or logic, endpoint renames, removal of attributes, or deprecated endpoints. Adding new attributes to existing responses is not considered a breaking change and does not result in a new version.

When a new version is published, the change is announced by email, and the previous version remains available for a 3-month deprecation period before it is retired.