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.