Reconnecting and revoking access
What breaks a connection, how to restore it, and how to cleanly remove Nodest's access to a tool
Connections don't usually break on their own — something changes at the provider. This page covers how to spot that, how to restore a connection, and how to remove Nodest's access deliberately when you're finished with a tool.
How do I know a connection has broken?
You find out through failures. Automations using the connection start failing, and Nodest notifies you when a run fails.
Open the failed run and look at the step that stopped it. Authentication problems surface as the provider's own error — unauthorised, forbidden, invalid token — rather than as a Nodest error. That's the signal that the credentials, not the configuration, are the problem.
A useful check: if several automations that share one connection all start failing at once, and they have nothing else in common, the connection is almost always the cause.
Why do connections break?
| Cause | What happened |
|---|---|
| Credentials rotated | An API key was regenerated or a password changed at the provider |
| Access revoked | Someone removed Nodest in the tool's connected-apps settings |
| Permissions reduced | The account Nodest uses lost rights to the resource |
| The account is gone | The person who authorised it left and their account was deactivated |
| The site moved | A WordPress site changed URL, or stopped being publicly reachable |
The last two catch people out most. An OAuth connection carries the permissions of whoever approved it, so deactivating that person's account can take working automations down with it.
How do I reconnect?
Reconnect from the workspace's connections screen, supplying the new credentials or re-approving access.
You don't need to touch your automations. They reference the connection, not the credentials inside it, so every automation using it recovers at once with no editing.
Nodest verifies the connection as you save it, so you'll know immediately whether the new credentials work.
What happens to runs that failed while it was broken?
They stay failed. A run is a record of what happened at the time, and reconnecting doesn't reach back and re-run it.
If the missed events matter, you'll need to trigger them again — re-save the records, resubmit the forms, or handle those cases manually. Worth checking the run history for the outage window so you know what was actually missed.
Fixing an inherited connection
WordPress plugin integrations run on the site connection rather than their own credentials. If WooCommerce, Gravity Forms, MemberPress or Easy Digital Downloads all fail together, fix the WordPress site connection — everything inheriting from it recovers at the same time.
Removing a connection
Removing a connection breaks every automation in that workspace that used it, immediately and without warning them — there are no fallback credentials.
Before removing one:
- Check what depends on it. Every automation in the workspace could be using it, including inherited plugin integrations if it's a WordPress site.
- Turn off or edit the affected automations, so they don't accumulate failed runs.
- Remove the connection in Nodest.
- Revoke access at the provider too. This is the step people skip. Removing the connection in Nodest stops Nodest using the credentials, but for OAuth it's good practice to also remove Nodest from the tool's connected-apps list, and for API keys to delete the key at the source. Otherwise a credential that still works is sitting unused.
Revoking without removing
If you want to cut access urgently, revoke at the provider first — that takes effect immediately regardless of what Nodest holds. Deleting an API key or removing Nodest's authorisation stops it working straight away.
Then tidy up the connection in Nodest afterwards.
