How to Automate User Access Reviews Across Unmanaged SaaS Using Unified APIs

If your engineering roadmap includes the requirement to "automate quarterly user access reviews across every SaaS app our customers use", you are staring down a massive architectural challenge. The implicit search query your enterprise customers are asking is how to automatically pull a list of users, roles, and access levels from every single application their employees use, without relying on manual spreadsheets.

Your product manager drops this requirement in a sprint planning meeting. The goal is to automate SOC 2, SOX, and ISO 27001 user access reviews. Your customers want to stop exporting CSVs and chasing department heads via Slack to confirm who still needs access to Jira, HubSpot, or the 100+ other tools their teams use.

As we covered in our developer tutorial on pulling user lists, automating this workflow requires moving beyond one-off API scripts. You need a highly scalable, unified architecture capable of normalizing identity data across hundreds of disparate systems. Building this yourself, one integration at a time, is an engineering trap. You will spend the next three years maintaining point-to-point connectors while fighting terrible vendor API documentation, aggressive rate limits, and undocumented edge cases.

This guide breaks down the architectural reality of identity sprawl, why point-to-point connectors fail at scale, and exactly how to automate quarterly user access reviews across unmanaged SaaS applications using a declarative Unified User Directory API.

The Compliance Nightmare: Why Manual User Access Reviews Break at Scale

Security frameworks like SOC 2 and SOX mandate periodic user access reviews (UARs). Organizations must prove that access to their systems is restricted to authorized personnel, based on the principle of least privilege, and that dormant accounts are promptly deprovisioned.

UARs are a hard compliance control. If a service organization's policies say they conduct quarterly logical access reviews, that organization will need to provide quarterly evidence from the preceding year confirming those reviews were conducted. Auditors want evidence the control operated throughout the observation period. The most common failure is having a policy that says user access is reviewed quarterly, but only being able to produce one access review from six months ago. The policy exists, but the evidence doesn't support that it operates as described.

Historically, IT and security teams handled this manually. The traditional workflow looks like this:

1. IT exports a CSV from every SaaS admin panel they have credentials to.
2. The list is split by application owner and emailed to managers.
3. Managers eyeball spreadsheets, cross-reference them against the HRIS, and rubber-stamp approvals.
4. Someone consolidates the responses into a master audit folder.
5. Three months later, repeat.

This manual process is a massive drain on resources and breaks immediately upon contact with reality. CSVs are inherently stale the moment they are exported. Apps without admin API access force IT to scrape UIs. Half the time, the right "manager" no longer works there.

If you are a GRC, SSPM, or identity governance product trying to automate this for your customers, you face an even harder problem: you don't have admin credentials at all. You have an OAuth connection from your end user, which means you need to programmatically pull the user list, role assignments, and last login data through whatever API the vendor offers. Multiply that by 100 SaaS apps per customer, and you have a severe engineering problem.

The Blind Spot: Unmanaged SaaS and Identity Sprawl

The standard engineering reflex when tasked with pulling user lists is to integrate with Okta, Microsoft Entra ID, or Google Workspace. If a customer wants user data, they should just pull it from the Identity Provider (IdP) via SCIM (System for Cross-domain Identity Management), a standard we detail in our guide to directory integrations.

This approach fails because SCIM and IdPs only see a visible slice of the SaaS estate. Connecting to major IdPs is table stakes, but it leaves a massive blind spot where the real risk lives.

Product-led growth has decentralized software purchasing. Marketing teams buy their own SEO tools. Engineering teams spin up new monitoring dashboards. Sales teams expense new prospecting software. Gartner projects that by 2027, 75% of employees will use technology outside of IT's purview. Organizations officially recognize only 10% of Shadow IT cloud services, which actually operate at ten times that amount. A typical business operates 108 identified cloud services, yet it secretly uses 975 additional cloud services that exist without detection.

Identity sprawl directly translates to breaches. Excessive permissions remain a leading cause of SaaS security incidents. Studies show that 85% of SaaS users have more privileges than their roles require, creating unnecessary attack surfaces. AppOmni's 2025 data reveals that 75% of organizations experienced a SaaS security incident in the past 12 months, with a significant number of these incidents tied to unauthorized applications.

The attack surface is growing exponentially. A 2026 Grip Security report found a year-over-year 490% spike in public SaaS attacks, with 80% of documented incidents involving PII and/or customer data. The poster boy example is the Salesloft Drift incident, where attackers stole active OAuth tokens used by customers to connect the Drift Chatbot to local Salesforce installations. Armed with legitimate tokens, attackers impersonated Drift and logged directly into Salesforce. One breach of a SaaS app cascaded into hundreds of compromises.

The takeaway: an access review program that only covers centralized IdPs misses the long tail of unmanaged SaaS. To provide genuine security value, your platform must connect directly to the underlying SaaS applications to audit local accounts, bypass shadow IT blind spots, and read the actual permissions granted within the app. For a deeper dive into this architectural gap, see our guide on the long tail of identity.

Why Building Point-to-Point Integrations for User Lists Fails

To audit the long tail of SaaS, you must integrate directly with the APIs of the applications your customers use. The instinct of every senior engineer staring at this requirement is to write a quick script. "It's just GET /users from each app, right?"

If you decide to build these point-to-point connectors in-house, the math quickly becomes terrifying. The average enterprise uses over 130 different SaaS applications. A realistic engineering team can ship two or three high-quality, production-grade integrations per quarter. Building 100+ this way means your access review feature ships in 2030.

The difficulty is not just writing the HTTP requests. Three weeks in, you will find your codebase infected with integration-specific logic trying to handle the following:

• Authentication Chaos: Application A uses standard OAuth 2.0 authorization code. Application B requires a static API key passed in a custom header. Application C requires you to exchange a signed JWT for a short-lived session token every 15 minutes. Others use Basic Auth or session cookies refreshed via post-install hooks. Each one is a separate code path with its own failure modes.
• Pagination Hell: Pagination is a tax on every endpoint. Application A uses cursor-based pagination (?after=). Application B uses offset and limit parameters (?page=). Application C uses HTTP Link headers (RFC 5988). Your sync job must handle all strategies flawlessly to ensure no users are skipped during an audit.
• Data Model Fragmentation: Field shapes rarely match a unified concept of a "user." HubSpot exposes contacts inside properties.firstname. Salesforce uses flat PascalCase. Workday calls them workers. Each provider has its own enums for status (e.g., active, suspended, deleted, archived) and license type.
• Rate Limits: Aggressive and undocumented. A single tenant scan of 5,000 users can burn the entire daily API quota for some applications.
• Missing Webhooks: Half of these applications do not emit user lifecycle events, forcing you to poll on a schedule.
• Silent Token Expiration: A nightly sync that worked for six months will quietly start failing when refresh tokens rotate or scopes change.

If you hardcode these differences, you end up with a massive, fragile codebase filled with if (provider === 'hubspot') statements. Every time a vendor deprecates an endpoint or changes a field name, your sync jobs break, your customers fail their compliance audits, and your engineering team drops feature work to fix technical debt.

graph TD
    Org[Organization / Workspace] -->|Contains| User[User]
    Org -->|Defines| Role[Role]
    Org -->|Defines| Group[Group]
    User -->|Belongs to| Group
    User -->|Granted access via| RoleAssignment[RoleAssignment]
    RoleAssignment -->|Links to| Role

curl -X GET "https://api.unified-platform.com/unified/user-directory/users?integrated_account_id=acc_123" \
  -H "x-api-key: $YOUR_API_KEY"

{
  "result": [
    {
      "id": "u_a91",
      "email": "jane@acme.com",
      "first_name": "Jane",
      "last_name": "Doe",
      "status": "active",
      "groups": ["engineering", "on-call"],
      "last_login_at": "2026-04-12T08:14:11Z",
      "remote_data": { "...the raw provider payload...": true }
    }
  ],
  "next_cursor": "eyJvZmZzZXQiOjEwMH0=",
  "result_count": 100
}

response.{
  "id": $string(id),
  "email": properties.email,
  "first_name": properties.firstname,
  "last_name": properties.lastname,
  "status": properties.archived = "true" ? "deactivated" : "active"
}

// Example: exponential backoff using normalized headers
async function fetchWithBackoff(url: string, attempt = 0): Promise<Response> {
  const res = await fetch(url, { headers: { 'x-api-key': process.env.API_KEY! } })
  if (res.status !== 429) return res
 
  const reset = Number(res.headers.get('ratelimit-reset') ?? 30)
  const jitter = Math.random() * 1000
  const delay = Math.min(reset * 1000, 2 ** attempt * 1000) + jitter
 
  console.log(`Rate limited. Sleeping for ${delay}ms...`);
  if (attempt >= 5) throw new Error('Rate limit retries exhausted')
  
  await new Promise(r => setTimeout(r, delay))
  return fetchWithBackoff(url, attempt + 1)
}