██FR█████ █INTELL███████████

Apigee API Product Design


This content originally appeared on DEV Community and was authored by Mahmoud Sayed

API Product Design in Apigee is a crucial strategic step that goes far beyond just bundling proxies. It’s about designing a product line for your APIs, focusing on the consumer’s needs, business value, and monetization.

Here’s a breakdown of the key aspects, considerations, and examples.

What is API Product Design?

It’s the process of defining how your API capabilities are packaged, priced, presented, and governed for different audiences. It answers questions like:

  • Who is this product for?
  • What capabilities do they get?
  • How much does it cost?
  • What are the usage limits?
  • How is it differentiated from other products?

Key Dimensions of API Product Design

You can think of designing an API product across four main dimensions:

1. Functional Scope (The “What”)

This defines the actual API resources (proxies, endpoints, and operations) included in the product.

  • By Capability: Grouping related functionality.
    • Example: A Weather-Data-Product includes /forecast, /current, and /alerts endpoints.
  • By Data Source: Grouping access to different datasets.
    • Example: A Financial-Data-Product includes stock-prices, forex-rates, and crypto-feed proxies.
  • By Granularity: Offering different levels of data detail.
    • Example: A User-Data-Basic product returns standard user fields, while a User-Data-Premium product includes sensitive data like email and phone number (with proper security!).

Design Choice: Do we create one giant product with everything, or many small, focused products? (Hint: Usually, many small products are better for targeting different audiences).

2. Audience & Access (The “Who”)

This defines who can see and use the product. Apigee manages this through API Product visibility and API Key verification.

  • Public: Anyone on the developer portal can see and request it. (e.g., Free-Tier).
  • Private: Only visible to specific individuals, groups, or teams. You must explicitly invite a developer. (e.g., Partner-Access, Internal-Apps).
  • Internal: A product not on the portal at all, only accessible by directly creating an App and Key in the Apigee admin UI. Used for internal service-to-service communication.

Design Choice: Is this product for external third-party developers, specific partners, or our own internal mobile apps?

3. Commercial & Usage Model (The “How Much”)

This is where you define the business model and operational limits.

  • Quotas & Rate Limits: The most common way to differentiate tiers.
    • Free Tier: 100 requests/day
    • Bronze Tier: 1,000 requests/day
    • Silver Tier: 10,000 requests/day
    • Gold Tier: 100,000 requests/day + 10 requests/second
  • Monetization:
    • Freemium: Free tier with paid upgrades (very common).
    • Pay-as-you-go: Price per X number of API calls.
    • Tiered Subscription: Fixed monthly price for a quota package.
    • Revenue Share: For partners driving transactions via your API.
  • Service Level Agreement (SLA): Higher-tier products can be associated with stricter SLAs (e.g., 99.95% uptime), though this is often managed operationally outside of Apigee.

Design Choice: How do we make money from this? How do we prevent abuse and ensure fair use?

4. Operational & Security Policy (The “Rules”)

This defines the policies enforced on the API product.

  • Security:
    • OAuth Scopes: A premium product might require a specific scope (e.g., scope=premium_data) in the OAuth token.
    • IP Whitelisting: A product for a trusted partner might have a policy that only allows calls from their known IP addresses.
  • Traffic Management:
    • Spike Arrest: Protect your backend from traffic spikes (e.g., 15 requests per second).
    • Response Caching: A product offering static reference data might have a cache applied to improve performance.

Design Choice: What extra policies (beyond quotas) are needed to protect the backend for this specific audience?

Practical Design Examples

Let’s design a product line for a hypothetical CompanyX API platform that offers Weather, News, and Currency data.

Example 1: The Onboarding Product

  • Product Name: CompanyX-Explorer
  • Audience: Public. New, unverified developers trying out the APIs.
  • Functional Scope: Read-only access to basic endpoints.
    • weather-api:/v1/current/{city}
    • news-api:/v1/headlines
    • currency-api:/v1/convert?from=USD&to=EUR (limited)
  • Commercial Model: Freemium. Free, no revenue.
  • Policies & Limits:
    • Quota: 100 requests/day, 5 requests/minute.
    • Spike Arrest: 5 requests/second.
    • Caching: None.
  • Purpose: Remove friction for sign-ups, let developers experiment and see value.

Example 2: The Targeted B2B Product

  • Product Name: CompanyX-Weather-Enterprise
  • Audience: Private. Specific enterprise customers who have signed a contract.
  • Functional Scope: Full access to all weather capabilities.
    • weather-api:/v1/current/{city}
    • weather-api:/v1/forecast/{city}
    • weather-api:/v1/historical/{city} (premium endpoint)
    • weather-api:/v1/alerts (premium endpoint)
  • Commercial Model: Tiered Subscription. $999/month.
  • Policies & Limits:
    • Quota: 500,000 requests/month, 50 requests/second.
    • Spike Arrest: 50 requests/second.
    • Security: May require a valid OAuth token with the historical_data scope.
  • Purpose: A high-value, revenue-generating product for serious business customers.

Example 3: The Internal Product

  • Product Name: internal-currency-data-consumer
  • Audience: Internal. The company’s own mobile app team.
  • Functional Scope: Full access to currency data for the app.
    • currency-api:/v1/convert
    • currency-api:/v1/history
  • Commercial Model: Not applicable. Internal cost.
  • Policies & Limits:
    • Quota: Very high or none. Trusted internal consumer.
    • Security: Might use a simpler authentication method or be whitelisted.
  • Purpose: Enable internal applications to consume APIs without going through the public developer portal.

The Design Workflow

  1. Identify Personas: Who are your developers? (e.g., hobbyists, startups, enterprises).
  2. Map Capabilities to Needs: What does each persona need? What are they willing to pay for?
  3. Bundle & Price: Create product bundles that meet those needs and assign a commercial model.
  4. Define Policies: Add the necessary quotas, security, and traffic rules to enforce the product design.
  5. Publish & Iterate: Publish the products to the portal, gather feedback, and adapt your product lineup.

In essence, API Product Design in Apigee is where business strategy meets technical implementation. It transforms your APIs from technical endpoints into valuable, marketable products.


This content originally appeared on DEV Community and was authored by Mahmoud Sayed