---
title: "Delete Experiment"
method: DELETE
path: "/api/v1/geo/experiments/{experiment_id}"
tags: ["geo-monitoring", "geo-hotels"]
---

# Delete Experiment

`DELETE /api/v1/geo/experiments/{experiment_id}`

Delete an experiment. 409 while one of its scans is still in flight.

Deletion relies entirely on the schema's existing cascade and retention
rules — nothing is cleaned up by hand here:

* ``geo_tracked_prompts``, ``geo_monitoring_runs``, ``geo_competitors``,
  ``geo_configured_competitors`` and ``geo_competitor_aliases`` are DELETED
  by their composite FKs to this experiment;
* ``geo_monitoring_tasks`` are deleted via their FK to the runs;
* ``geo_prompt_results`` are RETAINED and orphaned — ``tracked_prompt_id``
  and ``scan_id`` are both ``ON DELETE SET NULL`` — together with the
  ``geo_result_sources`` / ``geo_result_queries`` hanging off them.

Orphaned results are already invisible to every read path (the card query
filters ``tracked_prompt_id IS NOT NULL``; the Overview and Trends select by
``scan_id IN (run_ids)``, which a deleted run can never satisfy), so this is
the same retention behaviour prompt deletion has always had. Storage
reclamation is deliberately out of scope.

Deleting a grouped experiment removes only that experiment: its group
survives, and empties out if it was the last member.

## Path parameters

- `experiment_id` string, uuid, required

## Response `200`

Successful Response

- object

## Other responses

- `404` — Experiment not found
- `422` — Validation Error

---

[API](https://skmtc.dev/getanana/apis/cleon-api.md) · [All operations](https://skmtc.dev/getanana/apis/cleon-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/getanana/cleon-api/revisions/c0f54348e251/schema)