SaaS-to-SaaS integrations

what it is

SaaS-to-SaaS integrations are connections between two applications that operate automatically, without a human logging in to trigger them. A marketing automation tool that synchronizes contact records with a CRM. An HR platform that sends employee data to a payroll system. A customer support tool that pushes tickets into a project management application.

Each of these integrations is authorized by an API key, a service token, or an application-level OAuth grant. That credential gives one application permission to read from or write to another. The integration runs in the background, often continuously, and is typically set up once and then forgotten.

This is different from user OAuth grants, which are tied to a specific user account. SaaS-to-SaaS integration credentials exist at the application layer. They are not associated with a person, do not appear in user account lists, and are not touched by directory offboarding.

why it accumulates

Integration credentials accumulate for the same reason other SaaS access accumulates: creation is easy, cleanup is not.

Setting up an integration is a one-time task. The configuration is done, the integration runs, and the attention moves elsewhere. There is typically no process that revisits the integration to check whether it is still needed, still used, or still held by an application that is still in your stack.

When a tool is decommissioned, its integrations are often overlooked. The main application account is cancelled or removed, but the tokens it issued to other applications, or that other applications hold to reach it, stay in place. Those credentials may still be valid if the target application does not invalidate them when the source application stops using them.

Integration credentials also tend to be created by whomever set up the tool, often a technical member of a specific team rather than IT. When that person moves on, the integration has no clear owner. It continues running, or it sits dormant with a token nobody monitors.

what it costs you

Persistent access through decommissioned tools. An application that has been removed from your stack may still hold a valid API token granting access to another application that is still active. The decommissioned tool is no longer in use but its access credential is still live. If the vendor is acquired or their infrastructure is compromised, that token is a live access path into your environment.

Unmonitored data flows. SaaS-to-SaaS integrations move data between applications continuously. Without an inventory of what is connected to what, you do not know which applications receive which data. Customer records, employee data, financial information: the flows are real and may not align with your data residency or processing agreements.

GDPR data processor gaps. Applications receiving data from your environment through automated integrations are data processors. They require DPAs. Without an inventory of integrations, you cannot maintain a complete list of processors, and you cannot confirm that agreements are in place for all of them.

Credential theft impact. If an API key or integration token is exposed through a misconfiguration, an accidental commit, or a vendor breach, an attacker with that credential has the same access the integration has. For integrations with broad read or write access, the impact is significant. Most organizations do not know how many such tokens exist or what scope they carry.

what works

The inventory lives in two places. The first is the admin settings of the highest-value applications, the CRM, the HR system, the financial tools, the development platforms, where the list of API keys and connected applications shows what each connection is, what access it holds, and, where the platform records it, when it last ran. The second is any integration platform in use, Zapier, Make, Workato, which holds tokens on behalf of many applications and therefore doubles as a ready-made central inventory of at least the connections it manages.

Last-execution dates separate the living connections from the dead ones. An integration that has not run in months is a deactivation candidate, and the reasoning favors revoking over merely flagging: a dormant token grants the same access as an active one, carries the same theft and breach exposure, and provides nothing in return. The sharper version of the same logic applies to decommissioned tools, where the application is gone from the stack but tokens it was issued by other applications may still validate. Auditing the surviving applications for credentials issued to retired tools, and revoking them, closes access paths that no current process would otherwise ever touch.

Named ownership per integration is the step most environments skip and the one that determines whether the cleanup lasts. An integration with an owner gets questioned when its purpose lapses; an integration without one runs until something breaks or someone breaches it. Application-layer credentials never appear in user offboarding, which means an ownership review at each tool rotation, when a system is replaced or a builder leaves, is the only lifecycle these connections will ever have.