← All writing

February 15, 2026

API Management at Scale: Lessons from 220+ APIs

Managing a handful of APIs is straightforward. Managing 220+ across a large financial institution is an entirely different challenge. The problems shift from technical to organizational, and the solutions require as much communication as code.

Here's what I've learned leading API management at PNC.

Standards are the foundation

When dozens of teams are building APIs independently, inconsistency is the default. Different naming conventions, different error formats, different authentication patterns. It creates friction for every consumer.

The first thing we did was establish clear, opinionated API standards. Not guidelines. Standards. Naming conventions, versioning strategy, error response format, pagination patterns, security requirements. All documented, all enforced.

The key was making compliance easy. We built tooling that validates API specs against our standards before they enter the review process. Catching issues early means fewer painful conversations later.

Security is non-negotiable

In financial services, API security isn't a feature, it's a requirement. Every API goes through security review. Every vulnerability gets remediated on schedule. No exceptions.

We've built this into the workflow so it doesn't feel like a gate. Security scanning runs in the pipeline. Vulnerability reports are triaged weekly. Remediation is tracked alongside feature work, not as a separate process.

Governance without bureaucracy

The hardest part of API management at scale is governance that doesn't slow teams down. Too little oversight and you get chaos. Too much and you kill velocity.

Our approach is lightweight review for standard patterns and deeper architecture review for novel designs. Most APIs follow established patterns and sail through. The ones that don't get the attention they need.

Community drives adoption

Standards imposed from above get resisted. Standards built with the community get adopted. We run regular API standards discussions with developers across the organization. They propose changes, debate trade-offs, and help shape the direction.

When people feel ownership over the standards, compliance stops being a burden and becomes a shared commitment.