SearchAPI.io

Fronts the search endpoint of SearchAPI.io; the gateway fills in the secret api_key parameter on the query string:

GET /searchapi   → https://www.searchapi.io/api/v1/search?api_key=<secret>&<your query>

Only GET is mounted. The query string carries every control and goes upstream verbatim: engine (selecting google, google_maps, bing, …), q, location, num, and the rest. Beyond the key, the gateway adds no parameter and defaults no value — the call lands on SearchAPI.io exactly as if made directly.

Credential handling

Two credential channels exist on SearchAPI.io’s side — the api_key query parameter and a bearer token in Authorization. The gateway fills the first and deletes the second, closing off both:

• api_key is placed first in the query string, so it can’t be swallowed by a value with broken encoding.
• An api_key supplied by the client in the query is discarded (any encoding), so nothing can displace the injected key.
• Authorization is removed before the request goes upstream, which simultaneously shuts the second SearchAPI.io auth channel.

Examples

$
curl "$GATEWAY/searchapi?engine=google&q=coffee" \
>
  -H "Authorization: Bearer $TOKEN"

SearchAPI.io’s JSON comes back untouched. Per-engine parameters are listed in SearchAPI.io’s documentation.