Jina

Fronts the Search Foundation APIs of Jina — a family of products sharing one key but spread over several hosts. The sub-prefix after /jina tells the gateway which product, and therefore which host, to call:

GET|POST /jina/<service>/<path>   → <service host>/<path>

GET and POST are mounted, matching what these products document: Reader/Search take their target URL plus params via path and query on a GET, while the model APIs take a JSON body on a POST.

Services

Exactly these services are admitted; any other /jina/<service> is refused with the gateway’s own 404 and never reaches Jina.

Whatever follows /jina/<service> goes upstream untouched — e.g. /jina/reader/https://example.com → https://r.jina.ai/https://example.com.

Credential handling

Jina reads its key from Authorization: Bearer — the very header carrying your gateway token — so the gateway replaces that header with the Jina key:

• Authorization is overwritten with Jina’s secret key. Your gateway token stops at the gateway and never travels upstream.
• No query-param form of the key exists on Jina’s side, so nothing gets removed from the query string.

Examples

$
curl "$GATEWAY/jina/reader/https://example.com" \
>
  -H "Authorization: Bearer $TOKEN"

Responses arrive untouched — Jina’s JSON, or markdown/text in the Reader/Search case. Field-level request and response detail lives in Jina’s documentation; the gateway modifies neither.