Requests to ApsisApi may carry an x-api-key header. Nothing requires one, but running without a key costs you twice: tighter limits, and worse prices.

​
Keyed versus keyless

The keyless surcharge is folded into the spread component of the fee breakdown and is not itemized separately, so a keyless integration quietly quotes worse than a keyed one. If you are comparing Apsis pricing against another route, compare with a key. Sponsored gasless quotes (sponsor_fees) also require a key: the relay gas is charged to the funding balance of the partner the key belongs to. See SubmitGaslessOrder.

​
Getting a key

Keys are self-served from the partner panel at . Sign in with an email code, create a key, and copy it once.
1

Sign in

Request a code by email, then verify it. No password.
2

Create a key

Name it after the surface that uses it. Each partner has a cap on active keys.
3

Use it

Send it as x-api-key on every ApsisApi request.
The same flow is available programmatically through PartnerApi; see Partner panel.

​
Limits in practice

Limits are per minute and counted per key, so all your surfaces sharing one key share its budget. Use separate keys per application if you want them isolated from each other. Exceeding a limit returns RESOURCE_EXHAUSTED with the message rate limit exceeded. Back off and retry; the counter is a rolling per-minute window.
Do not put a key in a browser bundle you do not control. It is attributable to you and rate limited as one budget. For public frontends, proxy quote requests through your backend.

​
Key states

A missing header is not an error. The request is served as keyless. Key changes propagate within a few seconds: keys are cached in memory and refreshed on a short interval, so a key created or revoked in the panel is not effective instantly.