If you're already convinced that multi-gateway is the new normal for enterprise API programs, this post picks up where that argument leaves off. (If you're not — we made the case in When One Gateway Isn't Enough, which walks through the architectural pattern and why it matters.)

What that post doesn't give you is a way to actually score portal options against each other.

That's what this one is for. Six dimensions. Use them to evaluate any portal — native, custom-built, or third-party — against the realities of a program that spans multiple gateways.

What a developer portal actually is in this evaluation

Before scoring anything, it's worth being explicit about what's being evaluated, because the phrase "developer portal" still carries a decade-old definition that's no longer useful.

A modern enterprise developer portal is the control plane between API consumers and your gateways. It handles discovery, onboarding, credential lifecycle, access governance, documentation freshness, team collaboration, and integration with the rest of your enterprise stack (Gartner's guidance framework for evaluating API management solutions covers these as core developer-enablement capabilities). It is not "a docs site with a key-request form" — and any evaluation framework that treats it as one will produce the wrong answer.

With that frame, here are the six dimensions that actually determine whether a portal will hold up.

Dimension 1: Gateway coverage

The question: How many gateways can the portal talk to simultaneously, and at what level of fidelity?

This is the dimension most often underestimated. Native portals are, by design, single-gateway. Apigee Kickstart only talks to Apigee. Azure's built-in portal only sees Azure APIM. AWS's reference SAM application only knows AWS API Gateway. The moment your program adds a second gateway — for any reason — these portals either fragment your developer experience or require expensive bridging work.

How to score it: 

• Don't ask "does this portal support our current gateway?"

• Ask "if we acquired a company tomorrow that ran on a different gateway, what would happen to our developer experience?" Score against the gateway footprint you might plausibly have in two years, not the one you have today.

Dimension 2: Credential lifecycle and key storage

The question: What can the portal actually do with API keys beyond the initial issuance?

Most native portals issue keys cleanly. Where they diverge is everything after:

• Rotation — can keys rotate on a schedule, with grace periods so integrations don't break?

• Revocation — what happens when a partner relationship ends or a credential is compromised?

• External key storage — can keys live in your identity provider (Okta, Keycloak) rather than in the portal database?

• Cross-gateway normalization — when one developer needs an Apigee key/secret pair and an AWS API key for the same application, does the portal present that as one credential set or two?

How to score it: 

Walk through your actual credential governance requirements — rotation policies, revocation SLAs, external key storage, audit logging — and check each one against the portal's capabilities. "Issues keys" is the floor, not a passing score.

Dimension 3: Access governance and team management

The question: Who can see what, and how is that controlled?

Native portals tend to model access at the individual-developer level, with product visibility settings as the main lever. That works for small, public-facing programs. It doesn't scale to enterprise scenarios where:

• A partner organization needs five engineers to share applications and credentials

• A specific bundle of private API products should be visible to one team and invisible to everyone else

• Access requests need different approval paths depending on the API or the requester

The mature pattern is team-based access with private product bundles — sometimes called Access Groups. If your portal can't model "this team of developers has access to this bundle of APIs from these gateways," you'll end up modeling it in spreadsheets and IAM rules outside the portal.

How to score it: 

Sketch your three most complex access scenarios on paper. If the portal can't model them as configuration, it's a gap.

Dimension 4: Documentation freshness and format support

The question: How does documentation stay in sync with deployed APIs, and what spec formats does the portal understand?

The freshness question matters more than the format question, because stale docs erode developer trust faster than any other portal failure. Native portals generally rely on manual upload or revision-based publishing — which means documentation drift is inevitable.

The format question is less universal but increasingly important. REST/OpenAPI is table stakes. GraphQL services, AsyncAPI event streams, and legacy SOAP/WSDL endpoints often have to live in separate systems because the native portal doesn't render them as first-class citizens.

The mature pattern is CI/CD-driven documentation — spec updates published automatically as part of the deployment pipeline, so docs cannot drift from what's deployed.

How to score it: 

Ask "what's the path from a deployed API change to a published doc update?" If that path includes a human step that can be forgotten, freshness will degrade over time.

Dimension 5: Extensibility model

The question: When you need to integrate with your internal systems — and you will — what does that actually look like?

This is the dimension easiest to skip during evaluation and most painful to discover post-implementation. Every enterprise portal eventually needs to integrate with ticketing systems, identity providers, analytics platforms, notification channels, internal approval workflows. The extensibility model determines whether that's a configuration exercise or a developer project.

Three patterns worth comparing:

• Widget-based customization (Azure's approach) — HTML/CSS/JS that works for branding but requires development for any functional integration

• Module / theme customization (Apigee Kickstart's approach via Drupal) — broader than widgets, but constrained by the framework and requires specialized maintenance

• Event-driven / plugin systems — pub/sub event brokers and plugin architectures that let admins wire up integrations without custom development

How to score it: 

List every external system the portal needs to talk to today, plus the integrations on the near-term roadmap. Score each one against "configuration" vs. "developer project." The cumulative answer is the real cost.

Dimension 6: Identity and SSO

The question: What authentication protocols does the portal support, and how does it integrate with your existing identity stack?

This sounds basic, and at the protocol level it usually is — but the gaps matter. Apigee Kickstart historically supported SAML but not OAuth2/OIDC. AWS's reference portal is tied to Cognito. Azure's portal works cleanly with Azure AD but less cleanly with anything else.

How to score it: For multi-gateway programs, the question is whether the portal can act as a single identity-broker layer in front of every gateway, regardless of what each gateway's native identity model looks like. One-protocol portals don't pass this test.

Putting the framework to work

A few suggestions for actually using these six dimensions:

• Score against all six, not just the ones the current portal handles well. Native portals score very high on the dimensions they were designed for and zero on the ones they weren't. Aggregate scores hide that pattern — break the scoring out by dimension so the gaps are visible.

• Weight the dimensions by your actual program. A 200-developer partner ecosystem weights team management heavily. A program with strict credential rotation requirements weights credential lifecycle heavily. There's no universal weighting — but there's a wrong weighting, which is "whatever the current portal happens to score well on."

• Quantify the customization tax. For any dimension where the portal needs custom development, estimate the ongoing engineering hours. Compare that to portals where the same dimension is configuration. The math often surprises people.

• Talk to your developers — and your partners — about credential and onboarding friction specifically. This is where multi-gateway pain shows up first, and it's where the data is most actionable.

• If you want a faster diagnostic before doing a full evaluation, we built a 3-minute multi-gateway lock-in assessment that scores your organization across infrastructure, governance, and renewal-leverage dimensions. The framework above is the deep version of what the assessment surfaces quickly.

The three native-portal patterns, scored briefly

Most teams evaluating this are starting from one of three places. Each one has a characteristic shape against the framework above, and we've written detailed gateway-specific analyses for each:

• Apigee Kickstart customers: When Apigee Kickstart Stops Scaling — the specific ceilings teams hit on credential lifecycle, access governance, multi-gateway support, and Edge-to-X migration scenarios.

• Azure APIM customers: The Hidden Limits of Azure APIM's Built-in Developer Portal — where the widget-based extensibility model, individual-only developer model, and Azure-only catalog start to constrain enterprise programs.

• AWS API Gateway customers: Why AWS API Gateway Doesn't Have a Developer Portal — the build-vs-buy economics of the reference SAM application and what's actually involved in getting to a production-grade portal on AWS.

Each post walks through the gateway-specific limitations against the six-dimension framework here.

Where Apiboost fits

Apiboost is the portal layer we've built for the multi-gateway pattern. The architectural detail behind that — the plugin abstraction, sync orchestration, event-driven integration — is covered in When One Gateway Isn't Enough. What this post adds is the evaluation lens: how Apiboost scores against the same six dimensions you'd use to evaluate any portal.

Here's how Apiboost maps to the six dimensions:

• Gateway coverage — Apigee Edge, Apigee X, Azure APIM, and AWS API Gateway simultaneously. How multi-gateway works →

• Credential lifecycle — create, rotate, revoke across gateways, with external key storage via Okta and Keycloak. Governance overview →

• Access governance and team management — Access Groups for mapping private product bundles to teams or individual developers. Teams and access →

• Documentation freshness — CI/CD APIs publish OpenAPI, GraphQL, AsyncAPI, and WSDL automatically on deploy. CI/CD documentation → · API catalog →

• Extensibility — plugin system, event-driven pub/sub broker, modular architecture. Covered in the multi-gateway architecture page.

• Identity and SSO — SAML 2.0, OAuth2, and OIDC across all gateways. SSO support →

The gateway-specific comparison pages — Apigee, Azure APIM, AWS — show how this maps feature-by-feature against each native portal.

Want to skip ahead? Take the 3-minute assessment to see how your organization scores on lock-in exposure across multi-gateway infrastructure, governance, and renewal leverage. You'll get a tailored exposure tier and recommended next steps.

Apiboost is an independent developer portal that works across Apigee, Azure APIM, AWS API Gateway, and additional gateways. Founded by the team that built enterprise developer portals on Apigee Kickstart starting in 2018, Apiboost is a certified partner of both Google and Microsoft.