REST API: overview

Availability

The REST API and webhooks are available on the Business plan. Lower plans use the console. The API and extensions page lists ready-made integrations.

Principles

The API is a REST API in the strict sense:

• all traffic goes over HTTPS on port 443;
• responses are JSON;
• responses use standard HTTP status codes; a failed authentication returns 401;
• authentication is token-based, issued from the console and revocable at any time;
• every call is written to the workspace’s hash-chained audit log.

The examples below are indicative: exact paths and parameters are in your workspace’s reference documentation.

Authentication

An API token is issued in the console, API section. Treat it as a secret: it acts on behalf of the workspace within its scope.

GET /v1/devices
Authorization: Bearer <YOUR_TOKEN>
Accept: application/json

Never put a token in versioned code. Use a secrets vault or an environment variable.

Exposed resources

The resource families follow the product structure:

• sessions: create an attended session, retrieve the 6-digit join code, read session state;
• devices: list installed agents, online state, groups;
• audit: read events from the hash-chained log;
• users: technicians and roles, on the Business plan.

Every resource is paginated; responses include the stable identifiers to use in subsequent calls.

Webhooks

Webhooks (Business plan) push events to your infrastructure instead of forcing you to poll the API:

• session ended;
• unattended device connected or disconnected;
• audit events, for example a confirmed file transfer.

A delivered webhook is not proof on its own: cross-check sensitive events against the audit log. Point webhooks at an HTTPS endpoint you control; the endpoint must be reachable over port 443.

Common use cases

• Automate deployment: query the device list after a GPO or Intune rollout to confirm the whole fleet is online. See Installing and deploying the agent.
• Feed an ITSM tool: create an attended session from your ticketing system and retrieve the code to send to the user.
• Monitor: receive session events through webhooks and correlate them with your own supervision.

Console or API?

Use the API when the work is repetitive or must integrate with another system: provisioning, monitoring, ticket workflows. Use the console for interactive support work. Both drive the same workspace, so a session created through the API appears in the console and vice versa.

Example: create an attended session

POST /v1/sessions
Authorization: Bearer <YOUR_TOKEN>
Content-Type: application/json

{ "mode": "attended", "label": "Invoice workstation" }

The response carries the session identifier and the 6-digit code to send to the user. The request and its outcome are logged in the audit log like any console action.

Best practices

• Store tokens in a secrets vault, never in code.
• Read events from the log instead of polling the API continuously.
• Test webhooks with a test endpoint before production.
• Revoke a departing technician’s token immediately.

Going further

• Security model and encryption: what the API logs and how.
• Migrating from ScreenConnect: automate agent redeployment during a cutover.