---
title: "Report Process Conversation Deletions"
method: POST
path: "/api/processes/{process_id}/conversations/deletions"
---

# Report Process Conversation Deletions

`POST /api/processes/{process_id}/conversations/deletions`

A process reporting conversations the user deleted on ITS OWN disk, so
the cloud hides the archived copies (`cloud_sync_conversations`'s deletion
push).

The cloud cannot work this out for itself: conversation sync is push-only,
so a deleted conversation merely stops being pushed — indistinguishable
from an idle one. Its archive row therefore stayed `deleted_at=''` forever
and resurfaced on the user's other devices every time this process went
offline and the list fell back to the cache.

Distinct from `DELETE .../conversations/{session_id}` on purpose. That
route is for a conversation living on some OTHER process and relays the
delete to its owner. Here the owner is the caller and the files are
already gone, so there is nothing to relay — and relaying would bounce the
delete straight back into the caller's own store, which re-logs it and
re-reports it on every sweep.

Idempotent: re-reporting an id already stamped marks nothing (the UPDATE
is guarded on `deleted_at=''`), and an id the cloud never saw marks
nothing either. Both are fine — the caller clears its log on 200 either
way.

## Path parameters

- `process_id` string, required

## Headers

- `authorization` string, nullable

## Request body

- ConversationDeletionsIn
  - `session_ids` string[]

## Response `200`

Successful Response

- object

## Other responses

- `422` — Validation Error

---

[API](https://skmtc.dev/omicos/apis/omicos-server.md) · [All operations](https://skmtc.dev/omicos/apis/omicos-server/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/omicos/omicos-server/revisions/a00b94573ffe/schema)