geo-monitoring
geo-hotels

Delete Experiment

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.

delete/api/v1/geo/experiments/{experiment_id}

Path parameters

experiment_idstring uuid required

Response

Successful Response

object required

Changes

No recorded changes to this endpoint across all 1 revision of this API.