Skip to main content
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. 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.

Contact the LI.FI team

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.

​
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

See Rate Limits and API Authentication for how the x-lifi-api-key header works and why you should never expose your key client-side.