Keep a register of your integrations: what expires, what limits you and what gets retired

What goes in the register

One row per integration. Record the provider, what the app uses it for, where in the code it is called, the kind of credential, who owns the account, when the credential was created, any review or expiry date the provider shows, the permissions it holds, the limit that matters and how to test it on staging. Keep the register without any secret values. Its value is that when something fails or a notice arrives, someone can see within a minute what is affected and who can fix it.

• A blank date is information: write that the provider shows none.
• Name a person for each row, not a team.
• Record staging and production credentials separately.

Documented examples of what ends

Google refresh tokens can stop working after revocation, six months unused, the per-client cap of 100 or a seven-day life when an external app sits in Testing status. Google Maps marked the older Places services Legacy on 1 March 2025, with a promise of at least twelve months notice before decommissioning. Slack revokes webhook secrets it finds leaked. SendGrid deletes its event signing key pair if you switch signing off and save. AWS signed links die when the credentials that signed them do. Pipedrive's daily token budget scales with plan and seats and emails admins at 75 and 100 per cent.

• Each is from the provider's own documentation, as read on the checked date.
• Providers change; the register's job is to notice, not to predict.
• A credential with no visible expiry still needs a test.

Where notices live

Most providers publish changelogs, deprecation pages or documentation banners, and some email the account holder. None of these is guaranteed to reach the person who understands the code. The register should list, for each provider, the page or address where notices appear and who reads it. A monthly look at those pages against the register is the cheapest defence against surprise retirement.

• Subscribe the account holder's email to provider notices.
• Record the date of the last review.
• When a notice names something your row uses, date it and decide: fix, defer with a reason, or retire the feature.

A thirty-day rule

Pick a number of days before any visible expiry or review date at which a person is told, and write down what they must do: renew, rotate, or change a setting. Renewing and rotating stay with the account holder; a service that watches may tell you, with exact steps, but should not hold your production secrets. If usage is approaching a limit, show the figure and say whether the cause is traffic or retry behaviour.

• Rotate immediately if a credential may have leaked.
• After rotation, run the staging test again.
• Record the new date in the register.

How the paid outcomes relate

The monthly integration-health service keeps this register for up to three integrations from a fixed £195 a month, an untested price, and its terms are agreed in writing before it starts. The consolidation project, from £3,500 after a quote, moves up to four services behind one internal module so the register has one code location per provider. A single client's retry problem is a separate fixed £295 job. Payment follows agreed checks and sign-off.