Architecture Overview and Deployment Options

The RapidAPI Enterprise Hub is divided into two high-level components:

Management plane
Runtime component (RapidAPI Proxy/Gateway)

Management plane

The management plane is used to facilitate API discovery, testing, provisioning, analytics, API definitions, and more.

Management Plane Responsibility
Storing metadata about APIs in the Enterprise Hub
Storing information about users with access to the Enterprise Hub and connecting to existing SSO / LDAP systems
Serving the user interface that developers interact with to discover and view API details
Generating reports on API usage

Runtime component (RapidAPI Proxy/Gateway)

The runtime component is responsible for proxying API requests, validating request content, asserting access permissions, tracking analytics, and enforcing monetization models.

Runtime Component Responsibility
Enforcing gateway functionality: Authorization, rate limits, quota limits, transformations, etc.
Infinitely horizontally scalable with the ability to be deployed in multiple data centers
Is independent of the management plane (Proxy/Gateway still works even if it can't communicate with management plane)

Deployment options

There are three options for deploying the RapidAPI runtime component:

Deploying with existing third-party gateways
Deploying with RapidAPI's gateway
Multi-gateway deployment

Deployment with existing third-party gateways

When existing gateway services are already deployed and being utilized to manage APIs, RapidAPI can integrate with these gateways (via its Platform API) to:

Provision API access
Push analytics and metrics to the management plane

This approach fully relies on the gateways as the runtime component, so there is no new dependency or networking hop added to the API request flow. RapidAPI merely acts as a control and visibility component on top of the gateway.

📘
Gateway functionality
In this configuration, RapidAPI is not involved in the API requests' runtime, so all gateway functionality [transformations, rate limits, quota limits, etc.] is deferred, defined, and enforced on the existing API gateways.

🚧
Monetization
When utilizing only third-party API gateways, monetization of an API is no longer available as a feature. RapidAPI's monetization functionality is tightly coupled to our RapidAPI Proxy/Gateway. The only way to enforce transactional monetization pricing plans from RapidAPI is by having a RapidAPI component in the runtime.
There is a workaround for this:

Utilizing a third-party gateway integration for any API not requiring monetization, then utilizing the RapidAPI Proxy/Gateway for any API requiring monetization (mentioned below in Multi-gateway deployment).

Deploying with RapidAPI's gateway

The most basic deployment includes deploying both the RapidAPI management plane and runtime component as a SaaS offering, managed by RapidAPI.

Multi-gateway deployment

Integrating with an existing API gateway and the RapidAPI Proxy are not mutually exclusive options.

This is a useful option when:

Some APIs have an existing gateway and other APIs do not.
Using an existing gateway for all internal APIs and the RapidAPI proxy/gateway for enforcing monetization of APIs that have been made available to external developers.