APIs and Apigee: The Business Value of APIs (Cloud Digital Leader)

An application programming interface (API) is a defined contract that lets one program request data or actions from another program: the caller sends a request in an agreed format and gets a response in an agreed format, without seeing or touching the code, servers or database behind it. People use applications through a user interface; programs use each other through APIs.

A familiar example is a fitness app that shows a user's sleep data from a wearable maker's platform. The app's developers never see the wearable company's systems. They send a request such as "sleep summary for this user, last night" to an interface the wearable company publishes, and its platform answers. How that platform stores or calculates the data stays hidden.

Because callers depend only on the contract, the provider can change everything behind it, rewriting the service in another language, moving it to new servers or changing its database, and callers keep working as long as the requests and responses stay the same. That stability is what makes APIs the building blocks of modern, connected applications.

Four properties together define an API, and each one separates it from another way of sharing a system:

Inside an organization, APIs create value by letting one capability be built once and reused everywhere, by decoupling applications from the systems behind them, and by replacing slow batch exchanges with on-demand access.

• Reuse across channels. An energy utility that offers its outage-status system through one API can feed its customer app, its text-message alerts and its call-centre screens the same live information, instead of building and maintaining a separate integration for each. A new channel later is just one more caller.
• Decoupling during modernization. A stable API layer between applications and an old backend lets the organization replace that backend in stages while the teams building on top keep working against an interface that does not change. A hospital group, for example, can swap out its patient-records system module by module while its patient portal keeps releasing features. Without that layer, every backend change ripples into every application. This ties APIs to the modernization approaches covered in the lesson on transitioning to the cloud (task 4.1).
• Real-time instead of batch. Batch transfers deliver data as it was at the last run. An API answers each request with current data within seconds, which is what quoting, tracking and booking experiences need.
• Faster delivery. Teams build new products by combining existing APIs rather than integrating with each system from scratch.

The principle behind all four: integration value comes from the interface, not from the infrastructure. Where a system runs, and what it runs on, does not change how easily other software can use it; a well-defined API does.

Exposing public-facing APIs creates new business opportunities by letting partners and outside developers build their own products on an organization's data or services, which brings the organization new channels, new customers and often new revenue at a scale it could not reach alone.

Examples of the pattern:

• A payment processor offers checkout APIs, so thousands of online stores embed its payments in their own sites and the processor earns a fee on each transaction.
• A city transit agency publishes real-time departure APIs, so map and journey-planning apps show its services to riders who never open the agency's own app.
• A car maker offers vehicle-data APIs that insurers and fleet managers use, with each driver's consent, to build usage-based products.
• A translation company that used to sign individual enterprise contracts adds self-service APIs, so developers anywhere can sign up, start calling and pay for what they use. Self-service is what lets an API reach a long tail of small customers that a direct sales model could never serve profitably.

The common thread is that other organizations' software uses the provider's live data or functions inside their own products. That is what separates an API business from simply publishing information for people to look at.

Opening an API is a controlled offer, not a handover. Every caller is still identified with credentials such as API keys or OAuth tokens, so the provider decides who may call; the provider still runs, secures and pays for the systems behind the API; and partner channels add to the organization's own channels rather than replacing them.

API monetization means earning revenue from API access, and the main models are consumption (pay per call or per unit used), recurring fees, one-time setup fees, revenue sharing, and free tiers that lead into paid plans. The right model depends on what the provider wants developers to do.

Notice the direction of revenue sharing. In the other models the developer pays the provider; in revenue sharing the provider pays the developer. It makes sense when each sale a partner brings in is worth more to the provider than any fee it could charge for the calls, as when a hotel group pays comparison sites a share of the bookings they generate.

Monetization in Apigee

Apigee supports these models with rate plans attached to API products (a bundle of APIs offered to developers). A rate plan is where the fees are defined: it can combine setup, recurring and consumption fees and revenue sharing. Developers are billed in one of two ways:

Keep the roles apart: a rate plan decides what a developer owes, and the billing type decides when it is paid. Limits on call volume and tools that track the provider's own cloud costs do neither.

Apigee API Management is Google Cloud's platform for managing APIs through their whole lifecycle, from design and security through traffic control, analytics, monetization and a developer portal, so an organization can run its APIs as products. It is the Google Cloud answer when APIs need to be secured, measured, published to partners and sold.

Apigee works by placing an API proxy in front of each existing API or backend. Callers talk to the proxy; the proxy applies policies (checking keys, enforcing limits, caching, transforming messages, logging) and then forwards the request to the backend. The backends stay where they are and keep their own code; Apigee adds a managed layer in front of them and nothing more.

This brings three kinds of business value:

• Consistency. Without a shared layer, every API in a portfolio tends to implement authentication, limits and logging in its own way, and every partner has to learn each one. Policies defined once in Apigee apply the same way to every proxy.
• Control and protection. Security and traffic rules are enforced centrally, before requests reach backend systems.
• Insight and growth. Analytics show who uses which API, while the developer portal and monetization turn APIs into products outside developers can find and pay for.

Modern APIs in front of legacy systems

Because proxies sit in front of whatever backend exists, Apigee can give partners modern, secured APIs over an old on-premises system right away, without rewriting or migrating that system first. Only the interface layer changes, so the business gets the partner-facing benefit without the cost and risk of a migration. The proxy layer then becomes the stable interface behind which the old system can be replaced later, at the organization's own pace.

Apigee secures APIs by verifying every caller's credentials at the proxy and protects backends by limiting how much traffic each caller can send, so unwanted or excessive requests are stopped before they reach any backend system.

• Identifying callers. Each developer app gets an API key, or obtains OAuth tokens. The proxy checks the key or token on every request and turns away callers that have not been approved. Access control is about who may make a call, which is a different question from how data is protected once a call is allowed.
• Quotas. A quota limits how many calls an app can make in a period (for example per minute or per month), typically set per API key or per product plan.
• Spike arrest. Smooths sudden bursts of requests, so a burst from any single caller cannot flood the backend and slow the API for everyone.
• Response caching. Stores frequent responses at the proxy, so callers get faster answers and backends do less work.

The principle: only an enforced limit refuses calls. Reports, documentation and prices can describe, explain or discourage traffic, but none of them stops a request from reaching the backend.

Advanced API Security

Apigee Advanced API Security is an add-on that goes beyond keys and quotas, in two ways. It assesses API proxy configurations against security best practices and scores them, so the security team can find APIs that are missing important protections. And it detects API abuse from traffic patterns, catching misuse that looks legitimate request by request and that fixed limits therefore miss. Because it runs inside Apigee, it uses the same proxies and traffic data. Filtering at the network edge, in front of Apigee, blocks malicious traffic but has no view of how each API proxy is configured.

Apigee analytics tells the business how its APIs are used, and the developer portal lets outside developers adopt them on their own; together with policies and monetization, each feature does a distinct job.

API analytics records traffic, response times and errors per API, per API product and per developer app over time. Product managers use it to see which APIs and partners drive usage, where errors cluster, how adoption changes after a launch or a price change, and where to invest. It measures the behaviour of callers. That makes it different from tools that measure the provider's own side, such as its cloud costs or whether its backend servers are up.

A developer portal is a website where outside developers discover the available APIs, read documentation, register their apps and get API keys without contacting the provider's staff. Its business value is scale: adoption can grow to thousands of developers without a support person for each one. Apigee offers an integrated portal and a customizable Drupal-based portal, both of which can be branded.

Google Cloud has three ways to put a managed front door on APIs: Apigee for full API management, and the lighter API Gateway and Cloud Endpoints for securing and monitoring APIs. Choose Apigee when APIs are a product, with monetization, a developer portal, and many partners to manage.

The backend type is not what decides between them; the business need is. A recipe platform that serves its own mobile app through API Gateway has what it needs for keys and monitoring. If it later wants to sell access to food-delivery partners on paid tiers, with self-service sign-up, those product needs point to Apigee. Cloud Load Balancing is not an API management product at all: it distributes traffic across backends but does not authenticate developers, meter calls or publish APIs.

Older study material sometimes describes a Cloud Endpoints developer portal. Cloud Endpoints Portal was deprecated in 2022 and shut down in 2023, so today a developer portal on Google Cloud means Apigee.

Apigee can run fully hosted by Google in Google Cloud, or as Apigee hybrid, where the runtime plane that processes API requests runs on Kubernetes clusters the customer manages in its own data centers or other environments, while Google hosts the management plane (the console, configuration and analytics).

Apigee hybrid fits organizations, such as healthcare providers or government agencies, that must keep API request processing in their own facilities for regulatory, data-residency or latency reasons but still want Google to run the management side. The comparison:

A rule about where processing happens is a rule about where the runtime runs. Proximity does not satisfy it: a Google Cloud region near a data center is still Google Cloud. Running a gateway entirely on the organization's own servers also keeps processing in-house, but then the organization runs the management side too, which is exactly what hybrid avoids.