account.application.deauthorized — losing access

What the event means

account.application.deauthorized fires when a connected account disconnects your platform, or when your platform's access is otherwise revoked.

What to do with it

Treat it as an integration failure rather than a detection input. Any monitoring depending on that account's data stops working from this point, and silently degraded monitoring is worse than none.

FeeGuard records the event in the audit trail as key.revoked and runs no detectors against it.

What breaks immediately

Once access is revoked, API calls scoped to that connected account fail with an authentication or permission error. Anything already in flight fails mid-operation.

For a reconciliation tool this is worse than a plain outage, because the failure is partial and quiet. Webhooks for other accounts keep arriving, the dashboard keeps updating, and only this one account silently stops being monitored.

A platform that does not handle this event explicitly will keep believing it has coverage it lost weeks ago. Silently degraded monitoring is more dangerous than none, because it is trusted.

Why it fires

The connected account disconnected deliberately. They left your platform, or an operator revoked the integration during a security review.

The platform revoked it. Offboarding a seller, usually correct and expected.

Stripe revoked it. Account closure, a compliance action, or a fraud determination on their side.

The event does not say which. If the distinction matters to your offboarding flow — and it usually does, since the first case may be recoverable and the third is not — it has to be inferred from your own records of what you or the seller did.

Handling it well

Record it in the audit trail. Losing access to a tenant's data is a material integration event and should be visible in the same place as key rotations and permission changes.

Stop scheduling work against that account. Historical scans and any queued jobs targeting it will now fail. Draining them proactively avoids a burst of retry noise that looks like an outage.

Do not delete existing findings. Discrepancies already detected remain valid — the money is still owed, and losing API access does not change that. What is lost is the ability to detect new ones or act on old ones automatically.

Tell someone. This is the class of event that should reach a human, because nobody will notice its absence.

Outstanding recoveries become unrecoverable

This is the consequence platforms most often miss. Any open finding against that connected account can no longer be acted on automatically — the API calls that would create a reversal will fail.

If there was recoverable money sitting with that seller, the window to collect it closed the moment access was revoked. Recovery from that point is a commercial conversation, not an API call.

A platform offboarding a seller with outstanding disputes should therefore reverse what it can *before* revoking access, not after. That ordering is easy to get wrong and expensive to discover afterwards.

Reconnection is not automatic

If the account reconnects later, monitoring does not resume by itself. A new authorisation is a new grant, and any historical window during which you had no access represents events you never saw.

Running a historical scan over the gap is the only way to recover that visibility. Treating reconnection as a fresh onboarding — rather than assuming continuity — is what prevents a permanent blind spot in the record.

What FeeGuard does with it

FeeGuard writes an audit entry with the action key.revoked and runs no detectors against the event. Existing findings are left intact, since the underlying money is unchanged.

It is a platform-level event

Unlike most Connect events, this one is delivered to the platform rather than carrying an account field in the usual way. That distinction matters when routing: a handler that only processes events with a connected-account attribution will drop it silently.

It is worth checking explicitly that your webhook endpoint is subscribed to it at all. Because nothing depends on it day to day, it is one of the easiest events to leave unchecked when configuring an endpoint — and its absence produces no symptom until the day it would have mattered.

Testing this path

This is one of the least-exercised code paths in any Connect integration, and one of the more consequential when it runs. It is also awkward to test, because triggering it for real means revoking access you then have to re-establish.

Stripe's CLI can send a synthetic event, which is enough to verify that the handler runs, the audit entry is written, and queued work is drained. It will not verify the harder part — that subsequent API calls against that account fail gracefully rather than throwing unhandled.

For that, point a test integration at a deliberately invalid key and confirm the failure surfaces as a tenant-visible integration error rather than a generic 500. The behaviour you want is the same in both cases: fail loudly to the operator, quietly to everyone else.

stripe trigger account.application.deauthorized

The event may be the only notice you get

There is no follow-up. Stripe does not resend it, and there is no status field on the connected account that a periodic poll would reliably catch in time.

If the handler throws, or the event is dropped because a worker was mid-deploy, the platform simply never learns that access was revoked. Everything continues to look fine.

That makes this one of the few events worth treating as critical rather than best-effort — retried on failure, and alerted on when the retries are exhausted. It is a small amount of work to protect against a failure mode that is otherwise entirely silent.