How to Publish APIs from Apigee to Developers

The API Publishing Problem

You have built APIs behind Apigee. They work. They are secured with policies. Rate limiting is in place. OAuth is configured. But external developers cannot discover them, cannot read documentation for them, and cannot get credentials to use them.

Publishing APIs means more than deploying proxies to Apigee. It means creating a complete self-service workflow that takes a developer from discovery to first API call without requiring manual intervention from your team.

This guide walks through the entire Apigee API publishing pipeline, step by step. By the end, you will know exactly what is required to make your APIs available to external developers through a developer portal.

The Apigee Publishing Pipeline

Publishing APIs from Apigee to developers requires six steps. Each step builds on the previous one. Skip a step and the pipeline breaks.

Backend Service
    ↓
Apigee API Proxy (security, rate limiting, analytics)
    ↓
Apigee API Product (bundles proxies, sets access controls)
    ↓
OpenAPI Specification (documents the API)
    ↓
Developer Portal (catalog, docs, credentials)
    ↓
Developer (discovers, tests, integrates)

1. 1.
   Create API Proxies in Apigee

   Deploy your backend services behind Apigee API proxies. Each proxy wraps a backend service and applies gateway-level policies. Add API key verification or OAuth token validation for security. Add rate limiting policies (SpikeArrest, Quota) to protect your backend. Add CORS policies if developers will call your APIs from browser-based applications. This is the foundation of the publishing pipeline. Without properly configured proxies, nothing else works.

2. 2.
   Write OpenAPI Specifications

   Document each API proxy with an OpenAPI 3.0 specification. The spec should include every endpoint path, HTTP method, request parameters, request body schemas, response schemas, authentication requirements, error codes, and example payloads. OpenAPI specs are the bridge between your API gateway and your developer portal. The portal uses them to generate interactive documentation. If your specs are incomplete or inaccurate, developers will get incomplete or inaccurate documentation.

3. 3.
   Bundle APIs into API Products

   Apigee API Products group related proxies and apply access controls at the product level. A product defines which API proxies a developer can access, which environments (sandbox, production) they can reach, and what rate limits apply. Products are what developers subscribe to. A developer does not subscribe to individual proxies. They subscribe to a product, and the product grants access to one or more proxies. Design your products around developer use cases, not around your internal service architecture.

4. 4.
   Set Up a Developer Portal

   The developer portal is the frontend where developers interact with your APIs. It renders OpenAPI specs as interactive documentation. It handles developer registration and authentication. It provisions API keys and credentials. It displays the API catalog so developers can browse and discover available products. Your portal options include the Apigee Integrated Portal (basic, limited customization), a custom-built portal using React or Next.js (flexible, expensive to build and maintain), or a managed platform like Centauri Launchpad (production-ready in 48 hours).

5. 5.
   Connect the Portal to Apigee

   The portal needs programmatic access to the Apigee Management APIs. This connection allows the portal to sync API products from Apigee, create developer entities when new users register, provision developer apps and generate API keys, and manage credentials. For Apigee X on Google Cloud, this means creating a GCP service account with the Apigee API Admin and Developer Admin IAM roles. The service account key or workload identity federation is used by the portal to authenticate against the Apigee Management API.

6. 6.
   Enable the Developer Self-Service Flow

   Once the portal is connected to Apigee, the entire developer onboarding flow becomes automated. No manual intervention is required from your API team.

This entire flow should happen in minutes, not days. If any step requires a human to approve, provision, or configure something manually, you have a bottleneck that will slow down developer adoption.

What Good API Publishing Looks Like

Not all developer portals are created equal. Here is what separates a portal that developers actually use from one they abandon after the first visit.

Common Mistakes

Teams that are new to API publishing consistently make the same mistakes. Avoid these to save months of rework.

• •Publishing proxies without OpenAPI specs. Without a spec, there is no documentation. Without documentation, developers cannot understand the API. They will not use it.
• •Manual credential provisioning. Requiring developers to email your team for API keys does not scale. It creates a bottleneck and frustrates developers. Automate credential provisioning through the portal.
• •No sandbox environment. When developers have no sandbox, they test in production. Production testing leads to bad data, unexpected load, and incidents. Always provide a separate sandbox environment in Apigee and expose it through your portal.
• •Outdated documentation. If your OpenAPI specs do not match the actual API behavior, developers will lose trust in your documentation and your platform. Keep specs in sync with your deployed proxies. Automate spec validation in your CI/CD pipeline.
• •No analytics visibility for developers. Developers need to see their own usage data to debug integration issues. If they cannot see error rates, response times, and quota consumption, they will file support tickets for problems they could solve themselves.

Automating with Centauri Launchpad

Centauri Launchpad automates the entire API publishing pipeline described above. Connect your Apigee organization by providing a GCP service account, and Launchpad handles the rest.

• •Imports API products directly from Apigee and keeps them in sync.
• •Generates interactive documentation from your OpenAPI specs using Scalar.
• •Handles developer registration, authentication, and SSO integration.
• •Provisions API keys and credentials automatically through the Apigee Management API.
• •Provides role-based access control so different developer groups see different APIs.
• •Deploys with your custom branding on your own domain.

The entire setup takes 48 hours instead of months. No Drupal. No custom frontend build. No ongoing portal maintenance for your engineering team.

Related Reading

• →How to Build a Developer Portal for Apigee
• →Apigee Developer Portal Architecture
• →What Is an Apigee Developer Portal?