---
title: "Record clearance of a legacy revoke_failed account"
method: POST
path: "/v1/admin/integrations/accounts/{account_id}/revoke-failure-clearances"
tags: ["admin"]
---

# Record clearance of a legacy revoke_failed account

`POST /v1/admin/integrations/accounts/{account_id}/revoke-failure-clearances`

## 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/admin/integrations/accounts/{account_id}/revoke-failure-clearances`
- Auth: HTTP bearer

Updates legacy revoke_failed rows to revoked. A confirmed upstream kill also clears the account's leak marker; declining confirmation preserves it. Reconnect does not wait for this clearance. The route refuses a live revoke debt and does not reactivate an account. Internal admin users only.

## Path parameters

- `account_id` string, uuid, required: Connected account with the legacy revoke_failed status.

## Request body

- RevokeFailureClearance: Which of the two decisions the operator is recording. Clearing a dead letter always means the same thing to the MEMBER — the fence lifts and they can connect that app again — but it can mean either of two opposite things about the CREDENTIAL, and the COGS orphan report needs to know which. Confirmed in the provider's console: it is dead, and reporting it as a live charge for ever is a false positive nobody can clear. Accepted as a leak: it may still be billing, and quietly dropping it from the report is how a real cost disappears. Required rather than defaulted, because either default silently answers a money question on the operator's behalf.
  - `upstream_confirmed_revoked` boolean, required: True when the operator verified in the provider's own console that the credential is gone. False when they are accepting a leak they could not kill — the account then stays on the orphan report, because it may still be billing.

## Response `200`

Successful Response

- RevokeFailureClearanceResult: What the operator's clearance did. ``cleared`` is false for two different reasons, and ``refusal`` says which. Reported rather than raised, so a double-click is a no-op with an honest answer instead of an error about a state the operator already wanted — but "nothing to do" and "a worker still owns this" are opposite next actions, so they are not reported as the same thing.
  - `account` string, required
  - `tenant_id` string, required
  - `cleared` boolean, required: False when the clearance did not take; see ``refusal`` for why.
  - `refusal` 'not_revoke_failed' | 'live_debt_exists': Why a revoke-failure clearance did not take. DERIVED at the point of refusal, never stored. This route clears a legacy ``revoke_failed`` row, with or without a confirmed kill; reconnect does not wait for it. - ``NOT_REVOKE_FAILED``: the row does not carry the legacy status. Nothing to change here. - ``LIVE_DEBT_EXISTS``: a non-terminal outbox debt still targets the credential. Wait for its settlement before recording a legacy clearance.
  - `still_reported_as_orphaned` boolean, required: True when the account remains on the COGS orphan report — either the operator accepted the leak, or the row was not theirs to clear.

## Other responses

- `401`: Unauthorized
- `403`: Permission denied (PERMISSION_DENIED) or email not verified (EMAIL_NOT_VERIFIED)
- `404`: Not found
- `409`: Conflict: admin write rejected on a state invariant. Inspect ``errors[0].type`` for the specific case (for example: ``self_action_forbidden``, ``already_disabled``, ``not_disabled``, ``last_internal_admin``, ``value_error``)
- `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)