DELETE
Delete file types
The blueprintIds field is used to specify the blueprint schemas (file types) that should be deleted. You can pass one or more IDs (up to 50) in a single request.
Warning: This action is irreversible.

Overview

Permanently deletes one or more blueprint schemas. This is a bulk operation: each blueprintId is deleted independently, one at a time, so it is possible for some IDs to succeed while others fail in the same request.
A partial failure does not fail the whole request. As long as at least one blueprintId is deleted, the endpoint returns 200 OK with success: true. Always check failedCount and errors rather than relying on success alone to detect partial failures — see Response below.

Request

Request Body

The request body must contain a JSON object with the following structure:

Request Examples

Single blueprint schema

Multiple blueprint schemas

Larger batches must be split across multiple requests — sending more than 50 blueprintIds is rejected with 422 VALIDATION_FAILED before any deletion runs.

Response

A 200 OK is returned whenever the request is authorized and the body is valid, even when some or all IDs fail — inspect the payload for per-ID outcomes.

All succeeded

Partial failure

Mixed valid/invalid IDs in the same request are handled independently — the valid ones are deleted and the rest are reported in errors, without failing the whole request:

Every ID failed

If none of the requested IDs could be deleted — for example, re-deleting IDs that were already deleted by a prior request — success is false:

Per-item error messages

errors[].message is always one of the following:

Error Responses

All error responses use the standard RFC 9457 problem envelope (application/problem+json).

401 Unauthorized

Returned when the x-api-key header is missing or invalid.

403 Forbidden

Returned when the API key is inactive, or when the key is a read-only key (READONLY_KEY) — delete is a write operation and is rejected for read-only keys regardless of whether any of the IDs exist.

422 Unprocessable Entity

Returned for request-level validation failures — distinct from an individual ID that doesn’t resolve to a blueprint, which is reported per-item in errors (see above), not as a 422:
  • blueprintIds is missing or empty.
  • blueprintIds contains more than 50 IDs.
  • blueprintIds is not an array of strings.
See Error responses for the full field reference and other common statuses (400, 404, 429, 500).

Important Notes

  • Irreversible action: deleted blueprint schemas cannot be recovered.
  • Independent, sequential processing: each blueprintId in the array is attempted separately, one at a time. One failing ID never blocks the others from being deleted.
  • Malformed IDs: an entry that isn’t a valid ID format is reported as a failed item in errors (not a request-level 422), alongside any other per-ID failure.
  • Duplicate IDs: duplicate blueprintIds in the same request are de-duplicated before processing.
  • Re-delete (not found): deleting a blueprintId that doesn’t exist — including one already deleted by a prior request — fails that item with "Schema is not found or already deleted" in errors rather than raising a request-level 404. This makes retries safe.
  • Batch size: at most 50 blueprintIds per request.
  • Permission checks: a read-only API key cannot delete anything and receives a 403 for the whole request, regardless of whether the IDs are valid.

Use Cases

  • Cleaning up unused or duplicate blueprint schemas.
  • Bulk removal of blueprint schemas as part of a workspace reset or migration.
  • Automated cleanup of temporary or test file types.

Best Practices

  • Check failedCount and inspect errors on every response, even when success is true, to detect partial failures.
  • Treat re-deleting an already-deleted blueprintId as a safe no-op ("Schema is not found or already deleted") rather than an unexpected error.
  • Split batches larger than 50 IDs across multiple requests.
  • Avoid using a read-only API key for this endpoint — it will always return 403.
This endpoint accepts an optional Idempotency-Key request header so a retry cannot apply the change twice. See Idempotent requests.

Authorizations

x-api-key
string
header
required

API key for authentication

Headers

Idempotency-Key
string

Optional opaque key (max 255 chars, UUIDv4 recommended) making this request idempotent for 24h: a retry with the same key and body replays the original response with Idempotent-Replayed: true.

Body

application/json
blueprintIds
string[]
required

File type ids to delete, at most 50 per request. Repeated ids are collapsed and processed once. A malformed id is reported in errors rather than failing the request.

Required array length: 1 - 50 elements
Example:

Response

The delete request was processed; inspect the payload for per-id outcomes

success
boolean
deletedCount
number
failedCount
number
errors
object[]