How can I verify my runs have been queued for deletion via the API?

LangSmith Product Help Observability & Evals
1

I am using the /api/v1/runs/delete endpoint to queue up specific traces / runs for deletion by passing session_id and applicable metadata filters. The response is very opaque simply indicating that runs have been queued for deletion.

I sent a few requests last week and have been periodically check if runs I expect to be deleted are still visible in the LangSmith platform. So far none have been removed, I will continue to monitor but wondering if there is an easier way to validate this.

We are trying to develop a pipeline for removing traces for compliance and this feedback loop is currently making it very tough to move the project forward.

Thanks!

2

Hi @benlammers, there isn’t a separate API to poll “deletion job status” today. A 200 from POST /api/v1/runs/delete means the delete was accepted and scheduled, not that traces are already gone.

What “queued for deletion” actually means

Per the Data purging for compliance guide:

  • Deletions run during non-peak times and are not instant.
  • LangSmith runs the delete job on the weekend.
  • There is no confirmation callback or completion payload. you verify by querying again.

The Delete Runs API returns an empty {} on success (no job ID, no count of traces matched).

So if you submitted requests last week and checked before the weekend batch, traces can still appear in the UI , that’s expected, not necessarily a failed request.

1. Verify the request was accepted (queued)

Minimum: POST /api/v1/runs/delete returns HTTP 200.

Enterprise (audit trail): Query audit logs for the delete_runs operation:

curl -G 'https://api.smith.langchain.com/api/v1/audit-logs' \
  -H 'X-API-Key: YOUR_API_KEY' \
  -H 'X-Organization-Id: YOUR_ORG_ID' \
  --data-urlencode 'operations=delete_runs' \
  --data-urlencode 'start_time=2026-05-26T00:00:00Z' \
  --data-urlencode 'limit=50'

See Audit logs. This confirms who called delete and when, not that every trace was purged.

2. Verify deletion actually completed

Re-query with the same criteria you used to delete, via list_runs / POST /api/v1/runs/query (trace query syntax).

Paginate until no results. For large scopes, count root runs before delete vs after.

Timing: Plan verification after the weekend delete window, not hours after the POST.

3. Suggested compliance pipeline pattern (this is a recommendation given the restrictions we have, and I have NOT personally tried it in production)

  1. Discover: list_runs with your compliance filter; collect root trace_ids (and session_id / project).
  2. Delete: POST /api/v1/runs/delete with explicit trace_ids + session_id in batches of ≤1000.
  3. Record: Store (trace_id, session_id, delete_requested_at) in your system of record.
  4. Verify: After the weekend, re-run the same list_runs query; assert zero matches.
  5. Audit (Enterprise): Correlate your records with delete_runs audit log events.

TLDR

  • Queued ≈ HTTP 200 from delete (optionally delete_runs in audit logs on Enterprise).
  • Deleted ≈ targeted traces no longer returned by list_runs / /runs/query after the weekend batch.
  • There is no job-status or completion webhook today. programmatic re-query is the supported verification path.

Doc Reference

3

Thanks @keenborder786 for the quick reply.

If my requests were correct and the deletions were queued last week should they have been deleted by now or is it possible they are still queued for next weekend.

I am trying to determine if the existence of the runs means I did not properly form my requests last week or if they are still queued for even the following weekend yet.

4

As per the official documentation here, they should be. It specifies the weekend, so if you queued the deletion last monday, ideally by now the traces should have been removed