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 an 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.

Rapid Runtime overview

The Hub Listing > Gateway tab in Studio is mostly using to configure the behavior of an API on the Rapid Runtime. 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 then sent by the Runtime 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 and response logs (up to 7 days)
• Automatic CORS handling when testing the API from Rapid's playground

Gateway DNS

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 value 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 only - this is the fastest and easiest approach and is usually recommended
• only the API provider's gateway(s) - this means API requests do not involve the Rapid Runtime
• a combination of Rapid Runtime and one or more API provider gateways

See API Gateways for information on how environment administrators can 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.

Firewall settings

📘

Rapid Runtime

This section, and the rest of this document, only applies if the API uses the Rapid Runtime.

For security reasons, you should protect your API and block requests coming from outside the Rapid infrastructure.

The Rapid Runtime adds an X-RapidAPI-Proxy-Secret header to every request. This header has a unique value for every API. If the header is missing or has a different value, you can assume the request is not coming from the Rapid Runtime.

In the Firewall Settings section of the Gateway tab, click Copy to copy the value of the X-RapidAPI-Proxy-Secret header to your clipboard. The API gateway used for this API (such as Amazon API Gateway) should check for this header and value on incoming requests.

List of IP addresses used by the Rapid Runtime

Every request coming from the Rapid Runtime will come from one of the following IP addresses. To increase your API's protection, you can allow only these IPs to send requests to your API. Or, if you already use an allow list for your API, you must add these IP addresses to the allow list.

Here is the complete list of IPs to allow:
Note that you must accept API requests from ALL IPs below, regardless of which region your servers are located in.

Threat protection

📘

Rapid Runtime

This section only applies if the API uses the Rapid Runtime.

Threat protection protects your API from SQL or JavaScript injection attacks. If enabled, the Rapid Runtime will automatically compare the paths, parameters, headers, and body (of types application/json, application/x-www-form-urlencoded, and non-binary data in multipart/form-data) of all requests against pre-defined RegEx patterns, and block matching requests from reaching your servers.

By default, threat protection is disabled for an API. In the API's Gateway tab, under Threat Protection, slide the Protect API from SQL or JavaScript injection attacks toggle to the right to enable it. If threat protection is enabled and the request is not valid, the Rapid Runtime will usually return a 400 status code with a message of bad request.

Note that threat protection does not apply to mocked endpoints, since no request is being forwarded from the Rapid Runtime.

If threat protection (the first toggle above) is enabled, the second toggle (Threat protection requires the "Content-Type" header...) is also displayed. By default, the second toggle is disabled (as shown above). This means that if the request includes a body and includes a Content-Type header, the value of that header must be set to application/json, application/x-www-form-urlencoded, or multipart/form-data. Any other value will usually return a 400 status code with a message of bad request. If this toggle is enabled, the value of the Content-Type header will not be verified by the Rapid Runtime.

Request schema validation

📘

Rapid Runtime

This section only applies if the API uses the Rapid Runtime.

Request schema validation uses the Rapid Runtime to protect your API from being sent query parameters and/or headers that are not defined in the API's specification.

📘

Path parameters

Path parameters are always validated by the Rapid Runtime, independent of other security settings. If the endpoint does not exist, the Rapid Runtime returns a message similar to Endpoint /product/fake does not exist (where /product is a real endpoint but no path parameters were defined for the \product endpoint).

You can enable or disable request schema validation under the Hub Listing > Gateway tab of your API's definition. Enable or disable it using the slider in the Request Schema Validation section, as shown below. By default, request schema validation is disabled.

When request schema validation is enabled, you will be able to choose from three settings:

Pass through everything (default): The Rapid Runtime passes the request to the API's gateway or hosting server without stripping any query parameters or headers.
Strip and passthrough: The Rapid Runtime strips query parameters or headers that are not defined in the API's specification and passes the request through to the API's gateway or hosting server.
Block: The Rapid Runtime blocks any request containing any query parameters or headers that are not defined in the API's specification. The message returned to the API consumer identifies the invalid query parameters and/or headers.

🚧

If the default HTTP headers or auto-generated headers for REST APIs are not explicitly defined in the specification or Transformations, the request will be blocked if you select "Block".

Request configurations

📘

Rapid Runtime

This section only applies if the API uses the Rapid Runtime.

Request size limit

You can specify a maximum allowed request size (less than or equal to the default value of 50 MB). If left empty or configured as 0, the default value is applied. The request size includes the entire request line, including any 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.

Proxy timeout setting

You can specify a maximum allowed time for the Rapid Runtime to wait for a response from the API's gateway or hosting server (less than or equal to the default value of 180 seconds). If left empty or configured as 0, the default value is applied.

When the response takes longer than the specified timeout value, the Rapid Runtime terminates the request and a 504 status code is returned in the response.

Logging configurations

📘

Rapid Runtime

This section only applies for Enterprise Hub customers and only if the API is configured to use the Rapid Runtime.

API request/response logs can contain sensitive information such as personal identifiable information (PII), which you may not want Rapid's platform to save. With logging configurations, you can disable certain request/response log details for an API.

📘

Even if request/response logging is disabled, API analytics (number of calls, average latency, average error rate) and a log summary (username, endpoint called, status, etc.) are still maintained and available in the Developer Dashboard (Apps) and Studio (My APIs).

Request/response logging configurations can be changed in the Hub Listing > Gateway tab in the Logging Configurations section.

The screenshot above shows the default values. This logs all request and response details. You have the option to disable any or all of the following:

• Request headers
• Request query parameters
• Request bodies
• Response headers
• Response bodies

Secret headers and parameters

Rapid allows you to add secret headers and/or query parameters to API requests. The Rapid Runtime adds these secrets to every request, but are hidden from the API consumers.

📘

Tip: Uses for secret headers and parameters

If you already have API key generation for your API, you can use hidden parameters to authenticate your API requests. Create a single API key on your system for all requests coming from Rapid. You can then set that API key as a hidden header or parameter.

You could also use secret headers and parameters to set things like environment variable values that the API consumer would not know of or need to worry about.

📘

Difference between secrets and other authentication methods

Header and query authentication are similar to secret headers and parameters, with one key difference. For header and query authentication, the API consumer must set the value of the header or query parameter. For secret headers and parameters, the API consumer doesn't even know about the secrets. The values are set by the Rapid Runtime based on the values added when defining the API, as described below.

📘

Request headers sent by the Rapid Runtime

In addition to headers configured by the API provider and secret headers described here, the Rapid Runtime automatically sends other headers, such as the x-rapidapi-key header. For details on these headers, see Additional Request Headers.

Secret headers and parameters can be added for an API in the Hub Listing > Gateway tab in the Secret Headers & Parameters section.

You can add one or more name-value pairs that will be used as secrets. For each secret, specify Header or Query in the Type column, and optionally add a description to let others on the API provider team to know the purpose of the secret. In the example above, we have added one secret header and one secret query parameter.

When an API consumer calls an API endpoint, the header or query parameter name-value pairs will be sent by the Rapid Runtime and will be available to the API's implementation code.

Transformations

📘

Rapid Runtime

This section only applies if the API uses the Rapid Runtime.

For more information on request and response transformation, see Hub Listing - Request and Response Transformations (Gateway Tab).