> ## Documentation Index > Fetch the complete documentation index at: https://docs.fiddler.ai/llms.txt > Use this file to discover all available pages before exploring further. # Delete a dataset item > Delete one dataset item by appending a **deletion revision** (a revision that marks the item deleted) under a new committed version. The item is never physically removed: it disappears from the item listing, the item count and the dataset schema of the current dataset, and stays fully readable — content and all — at every earlier `?version=`. **Deleting an already-deleted item is 404**, not a second 204: a deleted item is simply not there, which is the same answer a GET or a PATCH of it gives. Nothing is written and no new version is created. Unlike the single-item PATCH, the optimistic-concurrency reference is a **query parameter** (`base_version`) rather than a body field, because a DELETE request takes no body. It takes the same version number as PATCH's `base_version` and `?version=`, and the same per-item rule: an older version is still accepted if this item has not changed since it. ## OpenAPI ````yaml DELETE /v3/evals/datasets/{dataset_id}/items/{item_id} openapi: 3.0.3 info: title: Fiddler API - 2.0 description: APIs to interact with Fiddler termsOfService: https://fiddler.ai/about/terms contact: email: support@fiddler.ai license: name: Proprietary url: '2.0' version: '2.0' servers: [] security: - BearerAuth: [] tags: - name: access-key description: CRUD operations for API keys - name: agent-v3 description: CRUD for the Agent Registry (Stage 1, manual entries) - name: aggregation-invalidation-request-v3 description: Endpoints related to retrieving aggregation invalidation requests - name: alert-rules-v3 description: CRUD for Alert Rules, Summary, and Stats APIs - name: application-v3 - name: auth description: Authentication strategies and login flows - name: baseline-v3 description: CRUD for baseline - name: catalog-v3 description: >- Entity catalog provides paginated, searchable discovery of entity names (attribute keys, agent names, span types, span names, score names, evaluator config names) and their distinct values. Powered by ClickHouse materialized views — no worker or PostgreSQL dependency. - name: chart-annotation-v3 description: Endpoints related to retrieving chart annotations - name: chart-v3 description: CRUD for chart - name: queries-v3 description: v3 queries API - name: configuration-v3 description: > Read and change runtime configurations (Config Manager) for your organization, its projects, and its models. **Private preview.** These endpoints accept requests on every deployment. Whether a saved value takes effect depends on two deployment settings that are off by default: one makes Fiddler read stored values, and the other runs the configuration worker, which applies retention changes to stored data. Contact your Fiddler Customer Success Manager before using these endpoints. This reference documents the data retention (TTL) settings: `PROD_EVENTS_TTL_DAYS`, `GENAI_TRACES_TTL_DAYS`, and `GENAI_METRICS_TTL_DAYS`. The API accepts other registered settings too; contact your Fiddler Customer Success Manager before changing any of them. **Retention settings permanently delete data** once it is older than the configured period. When existing data is affected depends on the setting; see each setting's description. - name: cost-evaluators-v3 description: > Paginated roll-up of per-evaluator LLM cost and token usage, aggregated hourly. Available only on deployments with evaluator cost reporting enabled. - name: custom-metrics-v3 - name: dimensionality-reduction-v3 - name: environment-v3 description: Endpoints related to environment management - name: evals - name: datasets - name: evaluation-v3 - name: evaluator-v3 - name: rule-evaluators-v3 - name: experiment-v3 - name: explainability-v3 - name: llm_rca-v3 - name: file-upload description: Endpoints related to file uploading. - name: fql-expressions-v3 description: > Endpoints for listing FQL (Fiddler Query Language) functions available for GenAI custom metrics. Used by the frontend for autocomplete and signature hints in the FQL editor. - name: genai-alert-rules-v3 description: CRUD API for GenAI Alert Rules - name: genai-custom-metrics-v3 description: API for GenAI Custom Metrics - name: genai-filters-v3 description: API for GenAI Filters - name: genai-metrics-v3 description: >- Endpoints for pre-aggregated GenAI metrics. All metric data is pre-aggregated hourly by a Celery-based metric collector; no real-time aggregation is performed at request time. - name: guardrails-api description: Endpoints related to retrieving Guardrails specific data - name: ingestion-v3 - name: intercom-api description: Endpoints related to intercom APIs - name: jobs-v3 - name: llm-gateway-v3 - name: auth-login - name: auth-logout - name: mcp-client-setup-v3 description: Endpoints for retrieving MCP client setup instructions. - name: metrics-v3 description: Metrics endpoints - name: model-v3 - name: dashboard-v3 - name: model-deployment-v3 - name: monitoring-summary-v3 - name: histograms-v3 - name: organization-roles-v3 description: Update user org role - name: organization-settings-v3 description: Update organization settings such as timezone, email configuration, etc. - name: pagerduty-api description: CRUD for Pagerduty services. - name: project-v3 - name: project-roles-v3 description: Project role assignment management - name: scores-v3 description: Unified CRUD for scores and annotations - name: searchable-text-key-v3 description: >- Manage the global searchable text keys table that controls which OTel attribute keys are routed to the full-text-searchable `ValueContent` column in the unified attributes table. Changes propagate to the backing ClickHouse dictionary within 1-2 minutes and affect all tenants. - name: segments-v3 - name: semantic-mapping-v3 description: >- Manage the global semantic name mappings table that maps raw OTel attribute keys to canonical semantic concepts. Changes propagate to the backing ClickHouse dictionary within 1-2 minutes and affect all tenants. - name: server-info-v3 description: Endpoints related to retrieving server information - name: service-account description: > Service accounts and their API keys. A human Org Admin manages the service accounts of their own organization: create, read, update, and enable/disable (there is no delete — an account is disabled instead), and issue, rename, enable/disable, and revoke each account's API keys (a key's expiry is fixed at creation and changed only by rotating the key). An API key is an `fks_` secret that inherits the account's grants and cannot manage service accounts; an active, unexpired key must be disabled before it can be revoked, and it authenticates only while both it and its account are active. Scopes here are capability scopes (what the account may do), not OAuth scopes. - name: sessions-v3 description: v3 session APIs - name: span-v3 - name: team-roles-v3 - name: team-v3 - name: traces-v3 description: v3 trace api for monitoring - name: fetch-sessions-v3 description: v3 fetch sessions api for monitoring - name: user-access-key description: > CRUD operations for user API keys. All endpoints are user-scoped — each user can only operate on their own API keys. No one including Org admins have access to other users' API keys. - name: users-v3 - name: version-compatibility-v3 - name: webhooks externalDocs: url: https://docs.fiddler.ai description: Find out more about Fiddler paths: /v3/evals/datasets/{dataset_id}/items/{item_id}: parameters: - name: dataset_id in: path description: Dataset UUID required: true schema: type: string format: uuid - name: item_id in: path description: Dataset item UUID required: true schema: type: string format: uuid delete: tags: - evals - datasets summary: Delete a dataset item description: >- Delete one dataset item by appending a **deletion revision** (a revision that marks the item deleted) under a new committed version. The item is never physically removed: it disappears from the item listing, the item count and the dataset schema of the current dataset, and stays fully readable — content and all — at every earlier `?version=`. **Deleting an already-deleted item is 404**, not a second 204: a deleted item is simply not there, which is the same answer a GET or a PATCH of it gives. Nothing is written and no new version is created. Unlike the single-item PATCH, the optimistic-concurrency reference is a **query parameter** (`base_version`) rather than a body field, because a DELETE request takes no body. It takes the same version number as PATCH's `base_version` and `?version=`, and the same per-item rule: an older version is still accepted if this item has not changed since it. operationId: deleteEvalsDatasetItemV3 parameters: - $ref: '#/components/parameters/dataset_item_base_version' responses: '204': description: The deletion was committed. Empty body. '400': $ref: '#/components/responses/400' '401': $ref: '#/components/responses/401' '403': $ref: '#/components/responses/403' '404': description: >- The dataset does not exist, the dataset has no live item with that id (unknown, belonging to another dataset, or already deleted), or `base_version` names no committed version of this dataset. content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '409': description: >- The write conflicted and no changes were made; switch on `errors[0].reason` to decide whether to retry. content: application/json: schema: $ref: '#/components/schemas/DatasetWriteConflictResponse' '500': $ref: '#/components/responses/500' '503': description: >- The data store was unavailable or too slow. No changes were made; retry with backoff. `errors[0].reason` is `DatasetItemsWriteUnavailable`. content: application/json: schema: $ref: '#/components/schemas/DatasetItemsWriteUnavailableResponse' components: parameters: dataset_item_base_version: name: base_version in: query description: >- Optimistic-concurrency check: the version the caller believes it is deleting. The request is refused with 409 if any revision of this item has landed above that version. Spelled exactly as `?version=` (a per-dataset version number) and resolved against committed versions only; an unresolvable value is a 404. required: true schema: type: string responses: '400': description: Bad Request content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '401': description: Unauthorized content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '403': description: Forbidden content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' '500': description: Internal Server Error content: application/json: schema: $ref: '#/components/schemas/ErrorResponse' schemas: ErrorResponse: type: object description: | Response object for errors returned by the API. properties: api_version: type: string default: '3.0' enum: - '2.0' - '3.0' description: | API version of the response. kind: type: string default: ERROR enum: - ERROR description: | Type of response, usually indicating an error. error: type: object properties: code: type: integer format: int32 description: > Represents the code for this error, typically an HTTP response code. default: 400 enum: - 400 - 401 - 403 - 404 - 409 - 410 - 422 - 429 - 500 - 501 - 503 message: type: string description: > A human-readable message providing more details about the error. If there are multiple errors, it will be the message for the first error. example: Resource Not Found errors: type: array description: > Container for additional information regarding the error, especially for multiple errors. items: type: object properties: reason: type: string description: > Unique identifier for this error, different from the error code. example: ResourceNotFoundException message: type: string description: > A human-readable message providing more details about the error. If there is only one error, this field will match error.message. example: Resource Not Found help: type: string description: > Link to support or documentation providing more information on the error. DatasetWriteConflictResponse: description: >- Error body of a `409` from a dataset write. No changes were made. `errors[0].reason` is the machine-readable discriminator. Kinds of conflict need different handling, so switch on it rather than on the status code alone: * `DatasetVersionCommitRace` — **transient; safe to retry unattended.** The write took too long to commit and another write took its place. The request is still valid, and replaying it commits under a new version. * `DatasetVersionSaveInProgress` — **transient; retry with backoff.** Another save holds the dataset. The request is still valid; resend it unchanged. * `DatasetItemStaleBaseVersion` — **never retry automatically.** An item the request names has a revision committed after its `base_version`; replaying would overwrite that edit. `errors[]` has one entry per conflicting id, up to 100, and `message` gives their total. Re-read the dataset and reconcile before writing again. * `DatasetItemCreateCollision` — **never retry unchanged.** Only `POST /evals/datasets/{dataset_id}/items` returns it: an `id` in the request is a live item with different content, or was written while this request was in flight (including by an earlier attempt of this same request). `errors[]` has one entry per colliding id, up to 100. Re-read the items: they may already hold this content. Any other value — including `Conflict`, the default every other endpoint returns — carries no retry guidance and should be treated as a plain `409`. allOf: - $ref: '#/components/schemas/ErrorResponse' DatasetItemsWriteUnavailableResponse: description: >- Error body of a `503` from a dataset item write. `errors[0].reason` is `DatasetItemsWriteUnavailable`: the data store was unavailable or too slow, and no changes were made. Retry with backoff; for a batch, send fewer items. allOf: - $ref: '#/components/schemas/ErrorResponse' securitySchemes: BearerAuth: type: http scheme: bearer ````