> ## 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. # Delete a durable snapshot > Accepts asynchronous deletion and returns 202 with `status: deleting`. The snapshot remains readable through GET and LIST while deletion completes; new sandbox launches from it are rejected. Repeating DELETE while `deleting` returns the same accepted response. Once deletion completes, GET returns 404. If deletion fails, the snapshot remains queryable in `delete_failed` with `failure_code` and `status_reason`. Resolve dependencies and repeat DELETE to retry. The snapshot remains unavailable for new launches. Existing dependencies that prevent deletion return 409. Creating snapshots may be cancelled with DELETE. A new snapshot request from the same source may still return 409 `Snapshot.CreateInProgress` temporarily after cancellation. Poll GET until 404 or `delete_failed`. Deleting and delete_failed records retain their names until deletion completes. A 202 response accepts deletion; it does not confirm that the snapshot is deleted. A creating snapshot cancelled with DELETE keeps its name until its creation deadline passes and deletion completes. A delete_failed snapshot cannot be renamed; retry DELETE to release its name. ## OpenAPI ````yaml /api-spec/sandbox_api.yaml delete /snapshots/{snapshot_id} openapi: 3.0.3 info: title: GMI Sandbox API description: >- REST API for GMI Sandbox: create isolated execution environments from templates or durable snapshots, 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: SandboxSnapshot description: Durable sandbox snapshot management (Sandbox v2, `/api/v2/snapshots`) - 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-Shell description: > Sandbox interactive terminal (PTY) data plane. **These endpoints are not under `/api/v2`**: clients connect directly to `https://{sandbox_key}.{domain}` and authenticate with `X-Access-Token`. `{sandbox_key}`, `{domain}` and the `X-Access-Token` value are the `sandbox_key`, `domain` and `sandbox_access_token` returned by the control-plane create/connect endpoints; no extra endpoint is needed. Each sandbox has exactly **one logical shell session** and at most **one active WebSocket connection** at a time (a second concurrent attach is refused at handshake with `409`). Disconnecting does not destroy the shell — re-attaching resumes the same session; only `POST /shell/control` with `action=close` destroys it. - 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: /snapshots/{snapshot_id}: parameters: - name: snapshot_id in: path required: true schema: type: string format: uuid delete: tags: - SandboxSnapshot summary: Delete a durable snapshot description: > Accepts asynchronous deletion and returns 202 with `status: deleting`. The snapshot remains readable through GET and LIST while deletion completes; new sandbox launches from it are rejected. Repeating DELETE while `deleting` returns the same accepted response. Once deletion completes, GET returns 404. If deletion fails, the snapshot remains queryable in `delete_failed` with `failure_code` and `status_reason`. Resolve dependencies and repeat DELETE to retry. The snapshot remains unavailable for new launches. Existing dependencies that prevent deletion return 409. Creating snapshots may be cancelled with DELETE. A new snapshot request from the same source may still return 409 `Snapshot.CreateInProgress` temporarily after cancellation. Poll GET until 404 or `delete_failed`. Deleting and delete_failed records retain their names until deletion completes. A 202 response accepts deletion; it does not confirm that the snapshot is deleted. A creating snapshot cancelled with DELETE keeps its name until its creation deadline passes and deletion completes. A delete_failed snapshot cannot be renamed; retry DELETE to release its name. operationId: deleteSandboxSnapshot responses: '202': description: Deletion accepted; poll GET until 404 or status=delete_failed. content: application/json: schema: type: object required: - request_id - data properties: request_id: type: string data: type: object required: - snapshot_id - status properties: snapshot_id: type: string format: uuid status: type: string enum: - deleting '400': $ref: '#/components/responses/BadRequest' '401': $ref: '#/components/responses/Unauthorized' '403': $ref: '#/components/responses/Forbidden' '404': $ref: '#/components/responses/NotFound' '409': description: >- State conflict. `Snapshot.HasDependencies`: the snapshot is still referenced by an active resource (for example a sandbox launched from it); remove the dependents and retry. Other state conflicts use `Resource.StateConflict`. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '500': $ref: '#/components/responses/InternalError' components: responses: BadRequest: description: >- Invalid request parameters. Two code families are used: `Request.InvalidParameter` for request parsing and format validation (unknown or malformed body fields, malformed IDs, invalid enum values, out-of-range paging) and `Parameter.Invalid` for business validation (for example a template or IDC that cannot be found, or a `timeout` over the limit). Unknown or invalid fields inside the `params` of `POST /sandboxes/{id}/actions` are reported as `Parameter.Invalid`. Other 400 codes are specific to an operation, for example `Sandbox.SourceConflict` (both or neither of `template_id` and `snapshot_id`) and `Sandbox.IdempotentParameterMismatch` (an `Idempotency-Key` reused with different parameters). Both code families share the same HTTP status, so decide by the `code` value, not the status alone. 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' NotFound: description: Resource not found content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: code: Resource.NotFound message: The requested resource was not found request_id: req-xxxx InternalError: description: Internal server error content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' example: code: System.Internal message: An internal server error occurred request_id: req-xxxx schemas: 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 trace_id: type: string description: >- Server-side trace identifier for this request; quote it when reporting a problem. details: type: object description: Field-level error details additionalProperties: true securitySchemes: bearerAuth: type: http scheme: bearer description: > API Key or Access Token, always sent as `Authorization: Bearer `. The gateway recognizes the token type automatically. ```` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.