integrations

Disconnect a connected account

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.

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

Path parameters

account_idstring uuid required

Headers

X-Tenant-Idstring nullable

Response

Successful Response

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_confirmedboolean required
grant_shared_with_another_connectionboolean

Changes

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