Adding a new third-party service, a payment processor, an email tool, an analytics widget, a customer support chat, usually takes minutes with an AI coding tool: install a package, paste in an API key, done. What rarely happens at the same time is a quick pass on what that specific integration can actually see or do once it's connected, which is worth a short checklist of its own.
What key or credential does this integration actually need
Most services offer more than one type of key: a broad, do-everything key and a narrower, scoped one for a specific purpose. It's faster to grab whichever key the documentation shows first, and that's often the broadest one available. Check whether the specific feature you're building actually needs full access, or whether a narrower, read-only or single-purpose key would do the same job with a smaller blast radius if it ever leaked.
Where does this key actually end up in your code
The same question that applies to every other key on this blog applies here: does it stay server-side, or does it end up somewhere the browser can read it because that was the fastest way to get the integration working. A quick grep through your frontend bundle for the new service's key naming pattern takes thirty seconds and answers this directly.
What data does this service now have a copy of
Sending user data to a third-party service, an email address to a mailing list tool, a name and order history to a support platform, means that data now lives in two places, with two separate sets of access controls, two separate breach risks, and two separate deletion paths to worry about if someone asks you to remove their information. Worth knowing this at the point you add the integration, not discovering it later when someone asks where their data actually lives.
Does this integration receive webhooks, and are they verified
If the new service calls back into your app, a payment confirmation, a delivery status, a chat message, that's a webhook endpoint, and it needs the same signature verification check I've written about before. A new integration is exactly the moment this gets skipped, because the excitement is in getting the connection working at all, not in verifying who's allowed to call it back.
What happens if this specific integration goes down or gets compromised
A quick thought exercise worth running on any new integration you're about to depend on: if this specific service had an outage, or if this specific key leaked, what would actually happen to your app? For some integrations, the answer is a minor inconvenience. For others, especially anything touching payments or user identity, it can be a much bigger exposure than the five-minute setup made it feel like.
None of this needs to slow down how fast you build. It's five extra minutes at the moment you add each new piece, against the alternative of discovering the answer to these questions later, under worse circumstances, after the integration's already been live for months.