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

# API Key Security

Eligible server-side and enterprise integrations can ask the LI.FI team about two additional controls: **IP allowlisting** (per key) and **dedicated instance lockdown** (per backend instance). These sit on top of the client-side-exposure guidance in [Rate Limits and API Authentication](/api-reference/rate-limits).

Availability and setup are confirmed case by case. These controls are not a substitute for keeping the key secret, monitoring its use, or rotating it if compromise is suspected.

# IP Allowlisting

An API key can be bound to an allowlist of source IP addresses. The binding is **per key**, not per integrator.

* Entries are IPv4 or IPv6 addresses or CIDR ranges. A bare address is treated as a single host (`/32` for IPv4, `/128` for IPv6).
* IP allowlisting is evaluated only for requests that send the `x-lifi-api-key` header. Other authentication or instance-level controls may still reject requests that omit the header.
* When LI.FI can determine the caller IP, a request using a restricted key is accepted only if that IP matches an allowlisted range. Requests from other sources are rejected **even if they supply the correct key value**.
* A denied request returns HTTP `403` with `{ "message": "Forbidden" }`. That body is not the usual LI.FI error envelope (it has no `code` field). An invalid key still returns `401`.
* If LI.FI cannot determine the caller IP, this control does not block the request. Use it as defense in depth for backends with a small, stable egress set (for example a fixed set of hosts or a NAT gateway), not as a guarantee that a stolen key is unusable from every network.
* Allowlist changes may not take effect immediately because key validation can be cached. Confirm that the new policy is active before relying on it. After a suspected leak, rotate the key; do not rely on tightening the allowlist alone for an immediate cutoff.

# Dedicated Instance Lockdown

For stricter isolation, LI.FI can provision a dedicated backend instance that restricts normal API traffic to specified integrator IDs and/or API keys.

* This is an **instance-level** deployment control, complementary to per-key IP allowlisting.
* On a locked-down instance, a request authenticated with a key that is not on that instance's allowlist receives HTTP `401 Unauthorized`, even if the key is valid on the shared LI.FI API.
* Exact hostname, topology, and which integrator IDs and/or API keys are admitted are agreed case by case. Do not assume a standard dedicated-instance contract.

# How to Configure

Neither control is a self-serve setting in the Partner Portal today. Contact the LI.FI team to confirm availability and arrange setup as part of onboarding or as a follow-up hardening step for an existing integration.

<Card title="Contact the LI.FI team" icon="envelope" href="https://li.fi/contact-us/">
  For IP allowlisting, identify the key(s) through the secure process the team provides and share the IPv4/IPv6 addresses or CIDR ranges to allow. For a dedicated instance, specify which integrator IDs and/or API keys must be admitted. Never send secret API key values in an unsecured support message.
</Card>

# Rollout Checklist

* Route server-side API traffic through a small, stable set of egress IPs, such as a NAT gateway.
* When changing networks, add and verify the new ranges before removing the old ones.
* Test from both an allowed source and a denied source before completing the rollout.
* After a suspected compromise, rotate the key even if you also update its allowlist.

# Related

<Note>See [Rate Limits and API Authentication](/api-reference/rate-limits) for how the `x-lifi-api-key` header works and why you should never expose your key client-side.</Note>