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.
Updated about 1 month ago