REST API

Last published : Oct 20, 2026
The Citrix SecurSpaces™ REST API exposes the platform's resources for automation: workspaces, projects, organizations, resources, users, and reporting. Anything the console does to a platform resource, the API can do.
The specification is served by your own deployment, at https://<your-sds-hostname>/api. That copy is the authoritative one, because it matches the version you are running. This page covers what the specification does not tell you: how to reach it, how to authenticate, and how the endpoints are arranged.
Note:
The REST API is controlled by a platform feature flag, which a platform administrator turns on. See Turn features on or off. Only users signed in to the platform can open the API documentation.
Related information
Reference

Open the API documentation

  1. Sign in to SecurSpaces.
  2. Select your profile picture at the top right of the screen to open the account menu.
  3. Select REST API.
Or browse directly to https://<your-sds-hostname>/api.
The SecurSpaces REST API documentation page
The page is an interactive specification browser. You can expand any operation to see its parameters, request body, and response schema, and call it directly from the page once you have authorized.

Authenticate with an API key

The API authenticates with an API key, sent in the Authorization header:
Scheme API key
Parameter name Authorization
Location Request header
Create a key in Profile > Security > API Keys. See Security.
A key carries the identity of the user who created it, so a request can only do what that user could do in the console. Treat it like a password, and revoke it from the same page if it is exposed.
To try operations from the documentation page itself, select Authorize and provide your key.

How the endpoints are organized

The API mirrors the platform hierarchy. Most resources exist at more than one scope, and the path tells you which one you are addressing:
Scope Path prefix What it addresses
Platform /v1/platform/... Deployment-wide configuration, regions, agreements, platform users and resources
Organization /v1/organizations/{organizationId}/... Everything belonging to one organization
Project /v1/projects/{projectId}/... Everything belonging to one project
So a data bucket, for example, is reachable at project, organization, and platform level, with the same shape at each. Choosing the scope is usually the first decision when you write against this API.
Alongside those, several resource families sit at the top level:
Path Covers
/v1/workspaces, /v1/personal_workspaces Workspaces, and the caller's own workspaces
/v1/workspace-images Container images available to workspaces
/v1/network-policies Network policy definitions
/v1/data-buckets Data buckets
/v1/metrics Usage and reporting data
/v1/groups Groups
Within the documentation page, operations are grouped by area — configuration, users, workspaces, resources, metrics, and status — at each scope.

The specification
Format OpenAPI 2.0 (Swagger)
Current version 1.1
Content type application/json
Version 1.1 defines 207 paths and 258 operations. Those figures move with the product, so treat your own deployment's specification as authoritative rather than this page.
Select Download OpenAPI JSON on the API page to save the specification. Use it to generate a client, to diff versions during an upgrade, or to drive contract tests.
The API page also lists what changed in the current version, including behavior changes that do not alter any route or schema — for example, a request that was previously accepted and silently ignored now being rejected. Read that section before an upgrade: a client can break without any endpoint having changed.

Endpoints used by IDE extensions

Workspace API responses include the vscode_version_id and vscode_version_auto_update fields, so administrators and integrations can identify the VS Code version assigned to a workspace. For a description of these fields, see IDE versions.
IDE extensions can also use these personal workspace endpoints:
  • GET /v1/personal_workspaces/{workspaceId} returns details for a personal workspace, including attached repositories, mount points, and data buckets.
  • DELETE /v1/personal_workspaces/{workspaceId} deletes a personal workspace belonging to the signed-in user.
  • GET /v1/personal_workspaces/{workspaceId}/connection_details returns what an extension needs to open a connection.
https://<your-sds-hostname>/version.json is served by the platform frontend rather than by the REST API. An extension can read it to check capability flags before calling version-specific endpoints, without authenticating first.

Manage VSCode versions through the API

The API includes VSCode version endpoints for automating the same version-management workflows available in the console. Use them to standardize IDE versions across scopes, import versions from a custom registry, and set a default version as part of an upgrade or environment build pipeline.
Version operations are available at these scope roots:
  • Platform: /v1/vscode-versions
  • Organization: /v1/organizations/{organizationId}/vscode-versions
  • Project: /v1/projects/{projectId}/vscode-versions
Each scope supports:
  • GET to list versions.
  • POST to import a version from a registry by image tag.
  • PATCH /{versionId}/name to rename a version.
  • DELETE /{versionId} to delete a version.
  • POST /{versionId}/default to set the scope default.
Platform-level custom registry management is also available through GET /v1/vscode-registries, POST /v1/vscode-registries, PATCH /v1/vscode-registries/{registryId}/name, and DELETE /v1/vscode-registries/{registryId}.
The endpoints enforce the same scope and permission checks as the console. A custom VSCode registry name must be unique within its scope, and each scope can have one custom registry.
For background about how IDE versions are resolved and used by workspaces, see IDE versions.