This document provides an overview of the Rapid Runtime, then provides details of the Hub Listing > Gateway tab in Studio. This tab is mostly used to configure the API's behavior when using the Rapid Runtime.
Note: For setting up an API's security strategy (such as OAuth), see Configuring API Security. This has moved to the Definitions tab in Studio.
The Hub Listing > Gateway tab in Studio is mostly using to configure the behavior of the Rapid Runtime for an API. The Rapid Runtime is a fast, highly-available, distributed proxy service hosted by Rapid. If the Runtime is used for an API, API requests sent by API consumers are first sent to the Runtime, and the Runtime usually forwards the request to the API provider's API gateway (such as Amazon API Gateway). Responses from the API provider's API gateway are sent to the Runtime, and the response is sent to the API consumer.
Using the Rapid Runtime for an API is fast and easy, and includes the following:
- Built-in security and threat protection mechanisms
- Enforced request timeout, rate, size, and/or quota limits
- Alerting if usage is abnormal
- API monetization
- API consumption, error rate, and latency tracking
- Automatically populated usage, performance, billing, and other analytics
- Endpoint response mocking
- Request and response transformations
- Detailed request/response logs (up to 7 days)
- Automatic CORS handling when testing the API
For rapidapi.com users, all APIs are automatically configured to (and must) use the Rapid Runtime. The Gateway DNS section of the Hub Listing > Gateway tab is for information only. The Gateway DNS will automatically be set to
rapidapi.com and can not be changed. This means that all API requests will be sent using the Rapid Runtime.
For Enterprise Hub customers, the Gateway DNS section of the Hub Listing > Gateway tab is used to specify if the Rapid Runtime is used for the API. Each API can be configured to use the Rapid Runtime (this is the fastest and easiest approach and is usually recommended), use only the API provider's gateway(s), or use a combination of both. See API Gateways for information on how environment admins configure non-Rapid Runtime API gateways. Once a gateway has been configured in the Enterprise Hub, it will appear in the dropdown in the Gateway DNS section of the Hub Listing > Gateway tab for all APIs, and API providers can choose a gateway or gateways from the dropdown (more info here). API consumers will then use the gateway(s) when testing the API or when obtaining sample code as described here.
For security reasons, you should protect your API and block requests coming from outside the Rapid infrastructure.
Rapid adds the X-RapidAPI-Proxy-Secret header on every request. This header has a unique value for every API, and if the header is missing or has a different value, you can assume the request is not coming from our infrastructure. The header for this API is: X-RapidAPI-Proxy-Secret followed by a unique string.
Every request coming from the Rapid Runtime will come from the following IP addresses. You can allow list these IPs, as they are the ones used to send requests only from Rapid.
A request coming from Rapid can be considered already authenticated, so no billing or authentication checks are required on the API side.
Here is the complete list of IPs to allow list:
Notice that you must accept API requests from ALL IPs below, regardless of which region your servers are located in.
By default, threat protection is off. You can toggle it on or off by clicking the switch.
If threat protection is enabled, the Content-Type header must be specified if the request has a body. If Content-Type is not specified, the request will be blocked. You can configure whether to block or pass the body through if the Content-Type is not set to application/json, application/x-www-form-urlencoded, and non-binary data in multipart/form-data.
You can enable or disable request schema validation under the Security tab of your API's definition. This stops requests that have a validation error at our Rapid Runtime so the call will not be sent to your API hosting server.
If enabled, we will automatically validate the path, query, and header parameters on run time and block all invalid requests. This requires a "Content-Type" header in requests with a body. By default, request schema validation is off. You can toggle it on or off by clicking the switch.
When Request Schema Validation is enabled, you will be able to choose from three settings:
Pass through everything (default): Request passed through without stripping any parameters or headers.
Strip and passthrough: Strips unexpected parameters or headers and passes the request through.
Block: Blocks any request with unexpected parameters or headers.
Currently, even if the default HTTP headers or auto-generated headers for REST APIs are not explicitly defined in the specification the request will be blocked if you select "Strip and passthrough" or "Block"
You can specify a maximum allowed request size (less than or equal to the default value 50 MB). If left empty or configured as 0, the default value is applied. The request size includes request line, header, and request body.
When the size of a request exceeds this limit, the request is blocked at the Rapid Runtime and a 413 status code is returned in the response.
Note: This section applies to Enterprise Hub customers only.
You can specify a maximum allowed time for the Rapid Runtime to wait for a response from the target API (less than or equal to the default value 180 seconds). If left empty or configured as 0, the default value is applied.
When the response from the target API takes longer than the specified timeout value, the Rapid Runtime terminates the call and a 504 status code is returned in the response.
Updated 39 minutes ago