Unplugged but Still Running: The Integration Loose Ends After a Tool Swap

There is a particular kind of relief when a software migration finally lands. The new tool is live, the old invoice is cancelled, and the team has stopped grumbling about the interface. Someone in IT disables the old user accounts, and everyone moves on. The trouble is that disabling a login is not the same as switching a system off. In the background, API keys can still authenticate, webhooks can still fire, and OAuth grants can still let third-party apps reach into data you thought you had left behind.

The logout that is not a shutdown

When you cancel a SaaS product, you usually lose the front door. The username and password stop working, the dashboard goes dark, and the billing page shows a satisfying zero. But integrations rarely use the front door. They use side entrances: long-lived API tokens, machine-to-machine credentials, and webhook subscriptions set up months ago by someone who has since changed jobs.

That is the gap a post-switch audit is designed to close. It is not about being paranoid. It is about recognising that a tool you have retired may still have a live connection to your CRM, your finance system or your customer database, and that connection may be invisible from the new tool's admin panel.

Three places the leftovers tend to hide

Start with the obvious suspects. In most small UK teams, lingering integrations cluster in three places.

API keys. These are often stored in places that are not really secret at all: a shared spreadsheet, a config file in a code repository, a password manager entry that nobody has opened since the last lockdown. When the old tool is retired, those keys are rarely revoked because nobody thinks to look.

Webhooks. A webhook is an instruction that says 'when something happens here, send a message there'. The 'there' might be your own endpoint, a Zapier-style automation, or a third-party service. If the old tool still has a webhook pointing at your infrastructure, it can keep sending payloads long after the subscription has ended, especially if the vendor keeps the endpoint alive for a grace period.

OAuth grants. These are the permissions you gave to a third-party app when someone clicked 'Allow' on a consent screen. They can persist independently of your user account, particularly if the grant was made at the organisation level rather than tied to an individual.

Who should actually hold the off switch?

The worst answer to 'who is revoking these?' is 'whoever gets to it'. In a small team, integration ownership tends to be diffuse: the operations manager set up the webhook, the developer added the API key, and the finance lead approved the subscription. When the tool is retired, each assumes someone else has dealt with the plumbing.

A better approach is to assign a single named owner for the post-switch audit, even if that person delegates the actual work. The owner does not need to be technical. They need the authority to ask awkward questions and the discipline to record the answers. In practice, that often means an IT lead, an operations manager, or a fractional IT provider who already handles your kit.

The owner's first job is to list every integration that touched the retired tool. The second job is to confirm, in writing, that each one has been revoked, redirected or deliberately retired. A short table is enough: integration name, type (API key, webhook, OAuth), who revoked it, and the date. Keep it somewhere the team can find it later, not in a personal inbox.

Testing for the quiet failures

Revocation is only half the job. The other half is proving that nothing is still running quietly in the background. Silent failures are common in integration work: a webhook returns a success code but the receiving endpoint ignores the payload, or an API key still authenticates but nobody is watching the logs.

A simple test is to check the outbound logs on your own side. If the old tool was sending webhooks to your infrastructure, look for recent requests from its IP range or user agent. If they are still arriving after the cancellation date, you have a loose end. If you cannot see the logs, ask your hosting provider or IT support whether request logging is switched on.

For API keys, the test is usually a staged revocation. Revoke the key, then watch for failed authentication attempts in the old tool's logs or in your own systems. If the key was still in use, something will break, and you will find out in a controlled way rather than at 4pm on a Friday.

The records that keep you honest

Under UK GDPR, you are expected to demonstrate accountability for the personal data you process. A retired integration that still has access to customer records is a data protection question, not just an IT tidy-up. If the Information Commissioner's Office ever asks how you handled a tool transition, a simple revocation log is far more convincing than a shrug.

The log does not need to be elaborate. Record what was revoked, when, and by whom. Do not store the actual API keys or secrets in the log; store the key identifier or a partial fingerprint. If a webhook was redirected rather than switched off, note where it now points and why. If an OAuth grant was left in place deliberately, say so and explain the business reason. That last point matters: an audit trail is not just a list of things you turned off, it is a record of the decisions you made.

A short checklist for the week after

• List every API key, webhook and OAuth grant connected to the retired tool.
• Assign one named owner for revocation and record-keeping.
• Revoke or redirect each integration, testing where possible.
• Check outbound logs for recent traffic from the old tool.
• Store the revocation log where the team can find it, without secrets.
• Diarise a follow-up check for 30 days later.

A tool swap is supposed to be a clean break. With a short, unglamorous audit, it can be. The seal on the old system is only as good as the checks you make after the login screen goes dark.