---
title: "Delete Subgraph"
method: POST
path: "/v1/graphs/{graph_id}/operations/delete-subgraph"
tags: ["Graph Operations"]
---

# Delete Subgraph

`POST /v1/graphs/{graph_id}/operations/delete-subgraph`

## Request

- Base URL: `https://api.robosystems.ai` (the document declares no server; this is the origin it was published from)
- URL: `https://api.robosystems.ai/v1/graphs/{graph_id}/operations/delete-subgraph`
- Auth: one of:
  - API key in header `X-API-Key`
  - HTTP bearer

Set `backup_first=true` to create a safety backup before deletion. Requires admin role on the parent graph.

**Idempotency**: supply an `Idempotency-Key` header to make safe retries; replays within 24 hours return the same envelope. Reusing the key with a different body returns HTTP 409 Conflict.

## Path parameters

- `graph_id` string, required

## Headers

- `Idempotency-Key` string, nullable

## Request body

- DeleteSubgraphOp: Body for the delete-subgraph operation.
  - `subgraph_name` string, required: Subgraph name to delete (e.g., 'dev', 'staging')
  - `force` boolean: Delete even if subgraph contains data
  - `backup_first` boolean: Take a full backup of the subgraph before deleting it. The backup is registered on the parent graph's backup list, where it can be listed and downloaded after the subgraph is gone. If the backup fails the subgraph is not deleted.

## Response `200`

Successful Response

- OperationEnvelope: Uniform response shape for every operation endpoint. Every dispatch carries an `op_<ULID>` operation_id, which is the bridge to the monitoring surface: pass it to `GET /v1/operations/{operation_id}/stream` (see `routers/operations.py`) to subscribe to SSE progress events. Sync commands complete in the envelope itself (`status: "completed"`, HTTP 200); async commands (`status: "pending"`, HTTP 202) hand off to a background worker and stream their tail through that SSE endpoint. Failed dispatches still mint an `operation_id` so the audit log and any partial SSE events stay correlatable. `TResult` parameterizes `result` so per-op response shapes surface in OpenAPI. Operations that pin `OperationSpec.result_type` get `OperationEnvelope[YourEnvelope]` as their response model; the rest keep the default `Any` shape (`result: any | null` on the wire).
  - `operation` string, required: Kebab-case operation name
  - `operationId` string, required: op_-prefixed ULID for audit and SSE correlation
  - `status` 'completed' | 'pending' | 'failed', required: Operation lifecycle state
  - `result` unknown
  - `at` string, required: ISO-8601 UTC timestamp
  - `createdBy` string, nullable: User ID that initiated the operation
  - `idempotentReplay` boolean: True when this envelope came from the idempotency cache — the underlying command did not execute again. False on fresh executions.

## Other responses

- `400`: Invalid request
- `401`: Authentication required
- `403`: Access denied
- `404`: Resource not found
- `409`: Idempotency-Key conflict — key reused with different body
- `422`: Validation error
- `429`: Rate limit exceeded
- `500`: Internal server error

---

[API](https://skmtc.dev/robosystems/apis/robosystems-api.md) · [All operations](https://skmtc.dev/robosystems/apis/robosystems-api/llms.txt) · [OpenAPI document](https://skmtc.dev/robosystems/apis/robosystems-api/revisions/e661e2d5ca6a?raw)