Shadow APIs outnumber known APIs 10-to-1 in financial services

The sprawl nobody talks about

Every fintech and financial services platform has the same problem: the number of APIs they’re actually calling is significantly larger than the number of APIs anyone can account for. Vendor integrations added by individual teams. Credentials that lived in a developer’s environment and made it to production. A three-year-old Zapier connection that still has production access to a core banking API.

Industry estimates consistently put shadow API connections — integrations that exist outside any formal registry or governance process — at ten times or more the count of officially managed ones. The ratio holds across organisations large and small.

This isn’t a technology failure. It’s what happens when moving fast is rewarded and maintaining inventory is nobody’s explicit job.

Why this matters specifically in financial services

In most industries, an undiscovered API credential is a security risk. In financial services, it’s also a regulatory exposure:

• PSD2 and open banking regulations require that third-party access to account data is explicitly consented to and auditable.
• SOX controls require that access to financial systems is limited to authorised personnel and processes.
• GDPR requires that every data processor with access to personal financial data is identified, contracted, and documented.
• SOC 2 Type II audits will ask “show me every system with access to this data” — and “we think we got them all” is not a passing answer.

A shadow integration — whether it’s an internal microservice calling a vendor API without proper credentials, or a long-forgotten webhook with access to transaction data — is a liability on all of these dimensions simultaneously.

What a managed API boundary looks like

The core fix is a proxy layer that all outbound API traffic routes through. Instead of services calling vendors directly, they call the gateway. The gateway holds the credentials, enforces access rules, and logs every call.

This isn’t just about security — it’s about having a single place to answer “what APIs does our platform call, and who calls them?”

In RequestRocket, every integration is a proxy record. Creating a new integration means creating a target, a credential, and a proxy — a deliberate act that creates a discoverable record:

POST /clients/{clientId}/targets
{
  "targetName": "plaid-api",
  "targetBaseURL": "https://production.plaid.com",
  "targetTestPath": "/institutions/get",
  "targetRegion": "us-east-1"
}

POST /clients/{clientId}/credentials
{
  "credentialType": "target",
  "credentialAuthType": "key",
  "credentialName": "plaid-production-key",
  "credentialRegion": "us-east-1",
  "credentialSecret": {
    "key": "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
  }
}

POST /clients/{clientId}/proxies
{
  "proxyName": "plaid-integration",
  "proxyRegion": "us-east-1",
  "proxyProxyCredentialId": "<internal-service-credential-id>",
  "proxyTargetId": "<plaid-api-target-id>",
  "proxyTargetCredentialId": "<plaid-production-key-id>",
  "proxyDefaultRuleEffect": "deny"
}

The GET /clients/{clientId}/proxies response is your live integration inventory — every outbound connection your platform makes, with credential and target information attached.

Turning proxy records into an audit trail

For compliance purposes, the request log is the evidence. Every call to a financial data API is recorded with credential, path, method, response status, and timestamp:

GET /clients/{clientId}/proxies/{proxyId}/requests
  ?processedAfter=2026-01-01T00:00:00Z
  &processedBefore=2026-04-23T00:00:00Z

For SOC 2 or regulatory audits, this gives you a point-in-time record of what was accessed and by which integration — without building a custom logging pipeline.

Enforcing least-privilege on every integration

Legacy shadow APIs often have broad permissions because nobody thought carefully about scope at the time. Bringing them under gateway governance is an opportunity to remediate this:

POST /clients/{clientId}/proxies/{proxyId}/rules
{
  "effect": "allow",
  "methods": ["GET"],
  "path": {
    "path": { "pattern": "^/transactions/get$" },
    "presence": "must_exist"
  },
  "priority": 10,
  "notes": "Plaid: read transaction data only — no account management operations"
}

A proxyDefaultRuleEffect: "deny" plus explicit allow rules means each integration can only do what it was provisioned to do. Credential leakage or misconfiguration can’t escalate into broader access.

The migration path

Discovering and centralising shadow integrations is a project, not a one-time fix. A practical approach:

1. Inventory existing integrations — review environment variables, secrets managers, and deployment configs across all services.
2. Migrate one integration at a time — create the target, credential, and proxy in RequestRocket; update the service to use the proxy endpoint; verify traffic; remove the direct credential.
3. Enforce gateway-only access — once all known integrations are centralised, add network-level controls (egress firewall rules, security groups) to prevent direct outbound connections to vendor APIs.
4. Prevent future sprawl — make “create a proxy” the standard process for adding any new vendor integration.

Next steps

If your team is facing an audit and can’t quickly answer “here is every third-party API we call and here’s the access log” — that’s the problem RequestRocket solves. Read the documentation or start for free.