## TL;DR
invalid_grant means the refresh token is dead because the rep revoked access, and retrying with it will never succeed. Detect the error, pause every agent step that touches Calendly, mark the integration disconnected, and have the rep re-authorize through the normal OAuth connect flow. Then resume the paused steps.

## The query

```text
calendly API invalid_grant after the rep revoked the agent's access
```

## Steps

### 1. Detect invalid_grant and stop retrying immediately
Match the error response for the invalid_grant code in the agent's Calendly calls. The moment it appears, stop all retries against that connection. Retrying a revoked grant burns quota and can look like credential abuse.

Expected: zero further API calls go out on the revoked connection.

### 2. Pause calendar-dependent agent steps
Find every agent workflow that books, reads, or cancels Calendly events for this rep and pause them. Queue the pending actions instead of dropping them, so nothing is lost while disconnected.

Expected: calendar steps are paused with their pending work queued, not failed.

### 3. Mark the integration disconnected and alert the rep
Update the integration status to disconnected in the agent's config and notify the rep (and the operator) that re-authorization is needed, with a direct link to the connect flow. Include what is paused so the rep understands the impact.

Expected: the rep gets a clear re-authorization request naming the paused workflows.

### 4. Re-run the OAuth connect flow and verify
Have the rep complete the Calendly OAuth authorization in a browser. Store the fresh tokens, make one read-only test call (list event types), and confirm it succeeds before resuming anything.

Expected: the test call returns 200 and the integration shows connected.

### 5. Resume the queued calendar work
Drain the queued actions in order, skipping any whose meeting time has already passed (notify the rep about those instead of booking stale meetings).

Expected: queued work completes and stale items are surfaced, not silently booked.

## Use this when

- Calendly API calls fail with invalid_grant
- A rep revoked the agent's access or changed their Calendly password
- Calendar steps fail for one rep while others work fine

## Not for this skill when

- Calls fail with 429 (that is rate limiting, not revoked access)
- Webhooks stop arriving but API calls still work (that is subscription expiry)
- Every rep's connection fails at once (that is an app-level problem)

## Variant phrasings

### calendly invalid_grant refresh token revoked
Token-level phrasing of the same failure. Same detect-pause-reauthorize flow.

### calendly api 401 after rep disconnected integration
Symptom phrasing. Confirm the error body says invalid_grant before treating it as revocation.

### rep revoked calendly access agent keeps failing
Operator phrasing. The key step is pausing before the rep re-authorizes.

## Why it happens
OAuth refresh tokens die when the user revokes the app, changes their password, or disconnects the integration. Calendly answers further token use with invalid_grant, which is permanent for that token. Agents that treat all 401s as transient keep retrying a token that can never work again, turning a one-minute re-authorization into hours of failed calls.

## Edge cases

- Some providers return invalid_grant for expired-but-revocable grants too. The handling is the same: re-authorize, do not retry.
- If the rep re-authorizes but the agent cached the old token, the failures continue. Clear the cached token on reconnect.
- Multiple agents sharing one rep's connection all need pausing. Track connections centrally, not per agent.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_b509QdYKxteb9bxZSttVSg