Keeping access alive
How Operate As renews connections, why access sometimes ends anyway, and how your client reconnects.
| When | What happens |
|---|---|
| Day 1 | Your client connects. The provider gives us short-lived access, usually about an hour, and a renewal key that gets fresh access |
| Every call | Under 5 minutes left? We renew first, then send the call. Your workflow never notices |
| Every day | Every connection not checked in the last day is renewed, whether or not your workflows used it |
| Some day | The provider refuses to renew: the client removed the app, changed a password, or an admin blocked it |
| Straight away | The service goes Expired, your team is alerted, the client gets their link, and your webhook gets connection.expired |
| Minutes later | The client opens their page from the email, confirms it's them with their passkey, and reconnects. New access replaces the old and workflows carry on, unchanged |
Automations run for months; sign-in access lasts about an hour. Operate As bridges the gap, and tells you the moment it can't.
Renewed before a call needs it
If the provider can't renew right now for reasons that aren't the client's doing, the call returns 503: "couldn't renew access right now. Try again shortly." The daily check tries again on its next run.
Pasted keys don't run out
Connections made with a pasted key aren't renewed. They work until the key is deleted or changed in the service. The daily check asks the service whether each key still works, where it has a way to tell, so a deleted key is found before a workflow hits it.
Why access ends
| Reason | What happened |
|---|---|
| Removed in the provider | The client removed the app in, say, their Google account's security page |
| Password changed | Google ends email access when the password changes |
| Unused for months | Google ends access unused for about six months |
| An admin blocked it | Google Workspace or Microsoft 365 admins can block apps |
| The provider refused | For its own reasons, such as a security review |
| Key deleted | For pasted keys: deleted or changed in the service |
Google's six-month rule rarely matters, because the daily check renews every connection whether or not it's used. It mostly catches connections that were already broken.
For a pasted key, the daily check asks the service whether the key still works and marks it Expired if the service refuses it. Between checks, a call with a deleted key gets the service's own error, such as 401, in the result's status.
What happens when access ends
The same things, whether the refusal comes at a call or at the daily check:
- Marked Expired. The client shows Needs reconnecting and is listed first.
- Team alerted with a dashboard notification and an email.
- Client emailed their link, with a Reconnect button, if you saved their email.
connection.expiredis sent to your webhook, with thereconnectUrl, if your plan includes webhooks.- Calls answer
409, with a message saying what to do.
Your team's email reads: "Miller Dental's Google access ended. Workflows using it will fail until they reconnect from their link." It says whether we emailed the client too. See Notifications.
Calls answer 409 instead of failing quietly:
{
"detail": "Miller Dental's Google access ended. Send them their link to reconnect."
}A provider the client never connected also answers 409: "hasn't connected Google yet. Send them their link."
How to recover
Send the client their link
It's the same link you sent the first time. Once a client has saved a passkey, their link keeps working for as long as they're your client. Get it from Copy link on the client, the Follow up list on Home, or reconnectUrl in the webhook.
They press Reconnect
They open their link, confirm it's them with their passkey, press Reconnect on the red card, and sign in to the service again.
Nothing to change on your side
New access replaces the old and the service is Connected again. Your workflows work as before.