> ## Documentation Index
> Fetch the complete documentation index at: https://docs.jojapi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# API Targeting

> Connect your API to the servers that run it: origins, headers and query parameters in the Worker template.

Most APIs on jojapi front a server you already run. The **template** describes where the edge gateway forwards a consumer's request and which headers and parameters it adds; the platform generates your API's Worker from it. Consumers only ever see `https://your-api.jojapi.net`.

<Info>
  APIs are moving to the **edge gateway**, where every API runs as its own Worker. The Worker tab of an API on the edge shows the template described here. APIs still on the classic gateway use the previous Target form and its [template expressions](/studio/target-transformations); they will be moved over time. The **My APIs** list shows which gateway serves each API: **Classic** (not moved yet), **Template** (edge gateway, Worker generated from the template) or **Code** (edge gateway, your own Worker code).
</Info>

Open your API in **Studio → Worker**. Every save of the template regenerates your API's Worker as a [preview](/studio/deployments#every-save-is-a-preview-first) within seconds; the confirmation tells you whether it built. Test it, then **Deploy to production** from the bar on the Worker tab.

## The template

**Origins**: one or more base URLs including any path prefix, e.g. `https://api.example.com/v2`. The consumer's path and query string are appended as they are: `/users/42?x=1` reaches `https://api.example.com/v2/users/42?x=1`. With several origins a request goes to one of them at random and moves on to the next when the first does not answer (network error or timeout), which gives you simple load balancing and failover. IP addresses and non-standard ports work too; such requests leave through the platform's egress relay, so the gateway's published IP addresses stay valid for your allowlists. A variable may stand in for the host: `https://{env.HOST}`.

**HTTP method**: the consumer's method, or an override.

**Timeout**: up to 90 seconds per origin (the platform's maximum).

**Request headers** and **query parameters**: add or overwrite values (a header can also be *removed* from the forwarded request). Values accept [placeholders](#placeholders).

**Switches**:

* *Forward the consumer's headers* — off means only the headers you set reach the origin.
* *Forward the consumer's query string* — off means only the parameters you set are sent.
* *Consumer context headers* — sends `x-jojapi-user-id`, `x-jojapi-user-nick`, `x-jojapi-user-plan` and `x-jojapi-endpoint-credits` to the origin, the way the classic gateway did.

**Proxy**: a secret variable holding your proxy URL (HTTP, HTTPS or SOCKS5, credentials included); requests then leave through the egress relay via your proxy.

## Beyond the template

Different origins or paths per endpoint, response rewrites, request body transformations, several upstream calls per request, or usage computed from the response body are matters of code. **View generated code** shows the Worker the template produces; **Edit code** takes it over. APIs moved from the classic gateway with endpoint-specific targets arrive in code mode already, with generated code that behaves exactly like their classic targets did. See [Worker code](/studio/custom-code).

## Placeholders

Header values and query parameters interpolate `{placeholder}` values from the request and the consumer's account:

| Placeholder | Value |
| - | - |
| `{path}` | the consumer's request path after the API host |
| `{method}` | the HTTP method |
| `{query.NAME}` | one query parameter, e.g. `{query.ip}` |
| `{header.NAME}` | one request header, e.g. `{header.accept}` |
| `{host}`, `{url}` | the API host the consumer called and the full URL |
| `{ip}`, `{country}` | the consumer's IP address and country code |
| `{user.id}`, `{user.username}` | the consumer's account id and username |
| `{plan.id}`, `{plan.type}` | the subscribed plan's slug and type (`periodic` or `payasyougo`) |
| `{endpoint.path}`, `{endpoint.credits}` | the matched endpoint |
| `{env.NAME}` | one of your [variables](#variables) |

The **Vars** button on each field lists them, including your variables.

## Variables

Variables are named values bound to your API's Worker. Use them for anything you would rather not type into the template: upstream API keys, tokens, a proxy URL.

* **Secret** variables are encrypted at rest and never shown again after you save them. To rotate one, save a new value under the same name.
* **Plain** variables are shown in Studio; use them for non-sensitive settings such as a region or a version.

Reference a variable as `{env.NAME}` in the template, or read `env.NAME` in [code](/studio/custom-code). Names use capital letters, digits and underscores, for example `UPSTREAM_API_KEY`.

<Tip>
  Static header values that looked like credentials were moved into secret variables automatically when your API was moved to the edge gateway.
</Tip>

## Billing

What each request costs is configured per endpoint in [Billable objects](/studio/billable-objects). Metered amounts come from structured **usage sources** (a response header, a header key, a JSON field) that the gateway reads from the origin's response, so a template API needs no code to bill by usage.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.