canonical: https://jentic.com/apis/kasmweb.com/kasm-workspaces

# Kasmweb Kasm Workspaces Developer API

Jentic publishes the only available OpenAPI specification for Kasm Workspaces Developer API, keeping it validated and agent-ready. Kasm Workspaces is a container streaming platform that delivers browser-isolated desktop and application sessions, and the Developer API exposes the operations needed to spin up sessions, manage users and groups, attach images, and update system configuration. All endpoints accept a JSON body containing api_key and api_key_secret for authentication and use POST regardless of resource type. The base URL is parameterised because Kasm is typically self-hosted and the host points at the customer's Kasm server.

## For AI agents

Provision and tear down browser-isolated container sessions, manage users and groups, and configure images on a self-hosted Kasm Workspaces server. 19 endpoints covering the session and identity workflow.

## Scope

Does not handle direct container image builds, host VM provisioning, or network firewall rules - use for Kasm Workspaces session, user, group, and image management only.

## Capabilities

- Create, list, update, and delete Kasm users via `/api/public/{create`,get,update,delete}_user endpoints
- Manage user attributes and SSO/group membership via `/api/public/get_attributes` and update_user_attributes
- Spin up and terminate streaming sessions via `/api/public/request_kasm` and `/api/public/destroy_kasm`
- List available container images and their assignments via image-management endpoints
- Manage groups and group memberships used for image entitlement and policy
- Force a user logout via `/api/public/logout_user` for incident response

## Use cases

### Just-In-Time Browser Isolation Sessions

Spin up a Kasm Workspaces session on demand for a security analyst opening a suspicious URL or a contractor accessing sensitive web apps. The `/api/public/request_kasm` endpoint accepts a user, image, and group, and returns a session URL that streams the container to the user's browser. Used by SOC teams and managed-service providers to put a disposable, network-isolated browser between the user and untrusted content.

Example prompt: Create a session for user analyst@example.com on the 'Chrome' image via POST `/api/public/request_kasm` and return the streaming URL.

### Contractor Onboarding and Offboarding

Provision Kasm users when a contractor is onboarded and remove them on the last day to avoid lingering access. The user-management endpoints cover create, update, attribute management, and delete, so an HR-driven automation can keep the Kasm directory in lockstep with the contractor's contract dates without manual admin intervention.

Example prompt: Create a user via POST `/api/public/create_user`, then schedule a delete via POST `/api/public/delete_user` when the contract ends.

### Group-Based Image Entitlements

Use Kasm groups to control which container images each cohort of users can launch - analysts get hardened browsers, engineers get developer images, and contractors get a minimal kiosk. The group and image endpoints let an automation provision the entitlement model in code so changes are version-controlled rather than clicked through the admin UI.

Example prompt: Add user {id} to the 'Analysts' group via the group-membership endpoint and verify by listing the group's user attributes.

### Incident Response Forced Logout

When a SOC sees a credential compromise on a Kasm user, an automation forcibly logs that user out of every active session via `/api/public/logout_user`, immediately killing the streaming containers. Combining with delete_user revokes future access. This brings response time from minutes to seconds compared with admin-UI clickthrough.

Example prompt: Force logout user analyst@example.com via POST `/api/public/logout_user` and confirm no active sessions remain.

### Agent-Driven Workspace Provisioning

An IT operations agent uses Jentic to provision a Kasm session when a help-desk ticket arrives ('I need an isolated browser to open this PDF') without the engineer logging into the admin UI. Jentic stores the api_key and api_key_secret in its vault and injects them at execution, so the agent's prompt never contains the secret pair.

Example prompt: Use the Jentic search 'spin up a Kasm session', load the schema, and request a Chrome session for the user identified in the ticket.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/api/public/create_user` | Create a Kasm user |
| POST | `/api/public/get_user` | Retrieve a single user |
| POST | `/api/public/get_users` | List all users |
| POST | `/api/public/update_user` | Update user properties |
| POST | `/api/public/delete_user` | Delete a user |
| POST | `/api/public/logout_user` | Force-log out a user |
| POST | `/api/public/get_attributes` | Get SSO and policy attributes for a user |

## Key resources

- **Users** — Create, list, update, and delete Kasm users with attributes.
- **Sessions** — Request and destroy streaming container sessions for users.
- **Images** — List and assign container images that back streaming sessions.
- **Groups** — Manage groups used for image entitlements and policy.

## Why Jentic

- **Setup:** Wiring the Kasm Workspaces Developer API by hand means learning its X-API-Key and api_key_secret pair, pointing calls at your own kasm_server host, and posting user and session actions as request bodies yourself. Through Jentic you install once, import the Kasm Workspaces Developer API from the API Directory, store the key pair once, and your agent calls it.
- **Permission scoping:** Kasm passes its targets in the POST request body rather than a resource id in the URL path, so limit the agent to the operations it needs, such as get_user and get_users. You choose that set, so a destructive one like delete_user is not included unless you add it.
- **Credential handling:** Your Kasm api_key and api_key_secret pair is stored once, encrypted, by your own Jentic One instance and injected at execution time. Neither half of the pair ever enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a Kasm user' or 'look up Kasm users', and Jentic returns the matching Kasm operation with its POST body schema so the agent calls the right endpoint without reading the Kasm developer docs.

## Related APIs

- **Docker Engine API** — Lower-level container API used to inspect the containers Kasm spins up.
- **TeamViewer API** — Remote-desktop access alternative without Kasm's per-session container isolation.
- **Zoom Meetings API** — Different category - used for live meetings, sometimes confused with browser-isolation tools.
- **Kandio** — Skill assessments delivered inside isolated Kasm sessions for cheating prevention.

## FAQ

### Why is there no official OpenAPI spec for Kasm Workspaces Developer API?

Kasm Technologies does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Kasm Workspaces Developer API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Kasm Workspaces Developer API use?

Each request sends an api_key and api_key_secret pair in the JSON body (header name `X-API-Key` is also used in the spec). Both halves are issued from the Kasm admin UI under Developer API. Through Jentic the pair is stored encrypted in the vault and injected at execution time so the agent never sees either secret.

### Can I provision a streaming Kasm session via the API?

Yes. POST `/api/public/request_kasm` with a user_id, image_id, and optional share flag returns a session ID and streaming URL that the user opens in their browser. POST `/api/public/destroy_kasm` tears the session down when the user is done.

### What are the rate limits for the Kasm Workspaces Developer API?

Because Kasm is self-hosted, throughput is bounded by the customer's deployment rather than a vendor quota. Each endpoint uses POST and is cheap to handle, but session-creation rate is limited by available container slots and agent capacity in the cluster.

### How do I onboard a new contractor in Kasm through Jentic?

Run `pip install jentic` and search Jentic for 'create a Kasm user'. Jentic returns the schema for POST `/api/public/create_user`; supply the username, password, and group memberships, then execute. Follow up with the group-membership endpoint to grant image entitlements.

### Why are all Kasm endpoints POST instead of GET?

The Kasm Developer API standardises on POST because every call carries the api_key and api_key_secret in the JSON body, which the platform considers safer than passing credentials in query strings or headers. Read-only endpoints like get_users are still POST for this reason.

### Is the Kasm Workspaces Developer API free to use?

API access is included with every paid Kasm Workspaces tier (Community, Standard, and Enterprise). The free Community edition supports the same Developer API surface as the paid tiers.

### Can I limit what my agent is allowed to do with the Kasm Workspaces Developer API?

Yes. Because you run Jentic One yourself, your own rules decide exactly which Kasm operations the agent can call, so you can allow read-only calls like get_user and get_users while withholding destructive ones like delete_user or logout_user. Kasm passes its targets in the POST request body rather than in the URL path, so scoping is done at the operation level: an operation is only available to the agent if you add it to its allowed set. Your api_key and api_key_secret pair is held by your own instance and injected at execution, so the agent acts only within the operations you permit.