---
title: "Disconnect a connected account"
method: DELETE
path: "/v1/integrations/accounts/{account_id}"
tags: ["integrations"]
---

# Disconnect a connected account

`DELETE /v1/integrations/accounts/{account_id}`

## Request

- Base URL: `https://api.patricia.app` (the document declares no server; this is the origin it was published from)
- URL: `https://api.patricia.app/v1/integrations/accounts/{account_id}`
- Auth: HTTP bearer

Soft-deletes the account and disables its tools, then best-effort revokes it at the provider. The response reports what the PROVIDER did (``upstream``/``upstream_confirmed``): the local disconnect always succeeds, so only ``upstream_confirmed`` may be shown as access removed. Requires either account-delete authority (owner/admin, which may disconnect ANY account) or the connect authority a member holds, which disconnects only a PERSONAL account they own. A Patricia-managed account is a 400. A foreign/unknown account, and any account the caller cannot see, both 404, so the route is never an existence oracle for another member's private connection; an account the caller CAN see but may not disconnect is a 403. An account that is visible AND the caller's own is also a 404 whenever its status is not ACTIVE (for example after a token failure parked it at `error`): there is no live access left to revoke, and reconnecting is the only route back to a disconnectable state. So a 404 here does not always mean the account is absent or foreign.

## Path parameters

- `account_id` string, uuid, required

## Headers

- `X-Tenant-Id` string, nullable

## Response `200`

Successful Response

- DisconnectAccountResponse: What the disconnect actually achieved, locally and at the provider. The local half always succeeds (the account is deactivated and its tools disabled), so a 200 alone would say nothing about whether the provider-side credential is still valid. These fields carry that truth to the caller, because "disconnected" is a claim about access, and telling someone their access was removed while their token still works is the one failure mode this endpoint must not have.
  - `upstream` 'revoked' | 'unsupported' | 'pending' | 'adapter_error' | 'intent_released_unresolved', required: What actually happened at the provider when we tried to revoke a disconnected account. Every value except ``REVOKED`` means the provider-side credential may still be LIVE, so they are kept apart rather than collapsed into success/failure: they carry different truths for the user and different remedies for us. - ``REVOKED``: the provider confirmed it. The only outcome that may be reported as "access removed". - ``UNSUPPORTED``: no kill is confirmed and nothing is retried (for example, the adapter raises ``NotImplementedError``, or declares ``revoke_confirms_upstream = False``). Nothing failed. A grant, or part of one, may still be live at the provider. - ``PENDING``: a real attempt failed against the provider (outage, timeout, HTTP error). Retrying later can succeed, so the account is flagged for the orphan report. - ``ADAPTER_ERROR``: the fault is on OUR side and no provider answer was recorded. Deliberately NOT "the request never left" — for the MCP path it never does, but a generic adapter can also die MID-call (``ADAPTER_BUG_EXCEPTIONS`` names that case), which leaves the provider's state unknown rather than untouched. Retrying the same input changes nothing; **a deploy, operator remediation, or configuration** does. Three shapes, and an on-call engineer needs all of them: our adapter is broken (a ``revoke`` whose signature no longer matches the call, a missing attribute, a typo), which a deploy fixes; the debt itself cannot be built into an authenticated request — an OAuth debt written before client identities were recorded, say — which no deploy can repair, because the missing part is data; or a signing key is absent, which is neither, and is repaired by setting it. Reading this as "only a deploy fixes this" sends someone hunting for a code bug that does not exist. It is a separate outcome from ``PENDING`` because our own failure, reported as a provider outage, is a failure nobody ever looks for. - ``INTENT_RELEASED_UNRESOLVED``: the native released-intent shortcut cannot confirm revocation, or an accountless Billit debt carries no token material. The row is terminal in one attempt and keeps its payload without a page. A tokenless account-backed Billit debt returns ``ADAPTER_ERROR`` and retries instead.
  - `upstream_confirmed` boolean, required
  - `grant_shared_with_another_connection` boolean

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/patricia/apis/patricia-api.md) · [All operations](https://skmtc.dev/patricia/apis/patricia-api/llms.txt) · [OpenAPI document](https://skmtc.dev/patricia/apis/patricia-api/revisions/0dfb44495ea1?raw)