> ## Documentation Index > Fetch the complete documentation index at: https://docs.gmicloud.ai/llms.txt > Use this file to discover all available pages before exploring further. # List active sandboxes > Returns sandboxes that are still actionable or still worth watching: `provisioning`, `running`, `updating`, `checkpointing`, plus the terminal failure state `failed`. Instances in transitional states do not disappear from the list while an operation is in flight. Results are ordered by `started_at` descending; pagination is applied after filtering. The `state` filter takes external states; the server maps them back to internal ones. `running` also matches instances in short-lived lease states (`updating` / `checkpointing`), because those mean "running but briefly busy" rather than a separately actionable state. ## OpenAPI ````yaml /api-spec/sandbox_api.yaml get /sandboxes openapi: 3.0.3 info: title: GMI Sandbox API description: >- REST API for GMI Sandbox: create isolated execution environments from templates, manage their lifecycle on the control plane, and run commands or transfer files through each sandbox's own data plane. contact: name: GMI Cloud Support email: support@gmicloud.ai version: '2.0' servers: - url: https://console.gmicloud.ai/api/v2 description: Control plane security: - bearerAuth: [] tags: - name: Sandbox description: | Sandbox instance lifecycle management (Sandbox v2, /api/v2/sandboxes) - name: SandboxTemplate description: Sandbox template management (Sandbox v2, `/api/v2/templates`) - name: Sandbox-Exec description: > Sandbox execution data plane (accessed via the sandbox host and sandbox access token). These endpoints are not under the control plane's `/api/v2` path; clients connect directly to `https://{sandbox_key}.{domain}` and authenticate with `X-Access-Token`. - name: Sandbox-Files description: > Sandbox file data plane (`/files`). **These endpoints are not under `/api/v2`** and do not use `Authorization: Bearer`: they are served by the sandbox's own data-plane entry point — clients connect directly to `https://{sandbox_key}.{domain}` and authenticate with `X-Access-Token`. `{sandbox_key}` is the `sandbox_key` returned by the create/connect endpoints, used for data-plane host addressing. `{domain}` and `X-Access-Token` are the `domain` and `sandbox_access_token` from the same responses — no extra endpoint is needed to obtain them. This split is not historical baggage but the nature of a data plane: file transfer is long-lived, high-volume, and addressed per sandbox, differing from the control plane's short requests in both capacity model and failure domain, so they do not share an entry point. **One unified abstraction.** The same contract is served by two backend kinds (an in-sandbox file service / a data-center data-plane proxy); clients need not — and cannot — tell them apart. The cost is that the contract is their intersection: `Content-Length` on download and resumable download (`Range`/`206`) are **optional capabilities** that vary by data center, and clients must work correctly when they are absent. See the per-operation notes below. paths: /sandboxes: get: tags: - Sandbox summary: List active sandboxes description: > Returns sandboxes that are still actionable or still worth watching: `provisioning`, `running`, `updating`, `checkpointing`, plus the terminal failure state `failed`. Instances in transitional states do not disappear from the list while an operation is in flight. Results are ordered by `started_at` descending; pagination is applied after filtering. The `state` filter takes external states; the server maps them back to internal ones. `running` also matches instances in short-lived lease states (`updating` / `checkpointing`), because those mean "running but briefly busy" rather than a separately actionable state. operationId: listSandboxes parameters: - $ref: '#/components/parameters/PageParam' - $ref: '#/components/parameters/PageSizeParam' - $ref: '#/components/parameters/IdcNameQueryParam' - name: state in: query description: Filter by external state. Repeatable; multiple values are OR-ed. required: false schema: type: array items: type: string enum: - provisioning - running - failed - name: metadata[key] in: query description: > Filter by customer metadata key/value, e.g. `metadata[job_id]=job-9182`. Repeatable; multiple filters are AND-ed. required: false schema: type: string responses: '200': description: Query succeeded content: application/json: schema: $ref: '#/components/schemas/ListSandboxesControlResponse' '400': $ref: '#/components/responses/BadRequest' '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/Forbidden' '500': $ref: '#/components/responses/InternalError' components: parameters: PageParam: name: page in: query description: Page number, starting from 1; default 1 schema: type: integer minimum: 1 default: 1 PageSizeParam: name: page_size in: query description: Items per page; default 20, maximum 100 schema: type: integer minimum: 1 maximum: 100 default: 20 IdcNameQueryParam: name: idc_name in: query description: Filter by data center name, e.g. us-denver-1 schema: type: string schemas: ListSandboxesControlResponse: type: object required: - request_id - total - page - page_size - items properties: request_id: type: string description: Request tracing ID total: type: integer description: Total number of active sandboxes page: type: integer page_size: type: integer items: type: array items: $ref: '#/components/schemas/SandboxControlSummary' SandboxControlSummary: type: object properties: id: type: string format: uuid description: >- Unique sandbox resource ID (UUID), used both in control-plane path parameters and as the billing resource_id. sandbox_key: type: string description: > Data-plane addressing key (an `i` followed by a 20-character random string). Used solely to assemble data-plane URLs: `https://{sandbox_key}.{domain}` and `https://{port}-{sandbox_key}.{domain}`. Control-plane endpoints always use `id` and do not accept this field. template_id: type: string idc_name: type: string state: $ref: '#/components/schemas/SandboxControlState' metadata: type: object additionalProperties: type: string created_at: type: string running_at: type: string ErrorResponse: type: object required: - code - message - request_id properties: code: type: string description: Machine-readable business error code example: Resource.QuotaExceeded message: type: string description: Human-readable error description example: The resource quota is not enough. request_id: type: string description: Tracing ID example: req-xxxx details: type: object description: Field-level error details additionalProperties: true SandboxControlState: type: string description: > External lifecycle state. The internal `creating` state is expressed externally as `provisioning` (the instance is being prepared and is not usable yet); backend queueing is not expressed separately and is also folded into `provisioning`. `deleting` is not listed here: once deletion is accepted the instance is no longer queryable (the detail endpoint returns 404), and that state appears only in the deletion endpoint's acceptance response. Suspend-related states likewise never appear — suspend is not offered externally. enum: - provisioning - running - checkpointing - updating - failed responses: BadRequest: description: Invalid request parameters content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: code: Parameter.Invalid message: Invalid request parameters request_id: req-xxxx Unauthorized: description: Unauthenticated content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: code: Auth.Unauthorized message: Authentication required request_id: req-xxxx Forbidden: description: The caller cannot access the organization-scoped resource. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' InternalError: description: Internal server error content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: code: Internal.ServerError message: An internal server error occurred request_id: req-xxxx securitySchemes: bearerAuth: type: http scheme: bearer description: > API Key or Access Token, always sent as `Authorization: Bearer `. The gateway recognizes the token type automatically. ````