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.