Kasmweb Kasm Workspaces Developer API
Agent-ready OpenAPI document · curated by JenticCloud InfrastructureContainer OrchestrationapiKey19 EndpointsREST
Know of an official OpenAPI document? Contribute it →
For 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.
Use for: I need to provision a new Kasm user for a contractor, Spin up a Kasm browser-isolation session for a security analyst, List all images available on the Kasm server, Force-log out a user from every active Kasm session
Not supported: 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.
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.
Install Jentic One Beta
Connect the Kasm Workspaces Developer API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Kasm Workspaces Developer API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fkasmweb.com%2Fkasm-workspaces" | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fkasmweb.com%2Fkasm-workspaces" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Kasm Workspaces Developer API.
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
Patterns agents use Kasm Workspaces Developer API for, with concrete tasks.
★ 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.
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.
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.
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.
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.
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
19 endpoints — jentic publishes the only available openapi specification for kasm workspaces developer api, keeping it validated and agent-ready.
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
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
Why Jentic?
What agents get from Jentic-routed access to this vendor.
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 isolation
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.
Intent-based discovery
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
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Kasm Workspaces Developer API through Jentic.
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.
GET STARTED