> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# IP allowlist
> Restrict access to your Lerian workspace to a list of trusted network addresses, for people who sign in and for systems that call the API.
The IP allowlist is a list of network addresses that your workspace trusts. When the list is active, Access Manager accepts requests only from those addresses. Everyone else is refused, even with a valid user name, password, or application credential.
Think of it as the guest list at the entrance of a building. The list belongs to the whole workspace, not to one person or one application. Whoever arrives from an address that is not on the list does not get in.
## What the allowlist protects
***
The allowlist has two switches. You can turn on one, the other, or both.
| Switch | What it restricts | Who it affects |
| ------------------ | -------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| **Console access** | People who sign in to the Console with a user account. | Your team: administrators, analysts, operators. |
| **API access** | Systems that call the Lerian APIs with your workspace's credentials. | Your integrations: ERPs, webhooks, scheduled jobs, application tokens. |
The two switches are independent. A workspace can restrict where people sign in from and still accept API calls from anywhere, or the other way around.
Do not turn on **API access** before you list every address your integrations call from. Those addresses are usually not the same ones your team uses to reach the Console. An integration that calls from an unlisted address stops at once.
## How the platform decides
***
Every request to a protected route goes through the same check, in this order:
1. A request arrives at the platform with your workspace's credentials.
2. The platform works out the network address the request came from. Behind your load balancer, it reads the address your proxy forwards. On BYOC, see [Deployment requirements](/en/platform/access-manager/features/ip-allowlist/deployment). On Lerian Cloud, Lerian handles this for you.
3. The platform checks whether the list is active for that kind of access: Console or API.
4. If the list is active, the platform compares the address with every entry on the list.
5. If the address matches an entry, the request continues. If it does not, the platform refuses it.
The platform repeats this check on every request. It does not decide once per session.
## What a refused person or system sees
***
A person who signs in from an unlisted address is refused. A system that calls the API from an unlisted address receives an HTTP `403` response with this body:
```json JSON theme={null}
{
"code": "AUT-0021",
"title": "IP Not Allowed",
"message": "Access from your network is not allowed for this workspace. Contact your administrator."
}
```
The code `AUT-0021` always means the same thing: the caller's address is outside an active list. It can come back from any protected endpoint of any Lerian product. See the [Access Manager error list](/en/reference/platform/access-manager/access-manager-error-list).
## What you can register
***
An entry is a single address or a range of addresses, in IPv4 or IPv6.
| You type | The platform stores | Why |
| ---------------- | ------------------- | --------------------------------------------------------- |
| `203.0.113.5` | `203.0.113.5/32` | A single IPv4 address is a range of one. |
| `2001:db8::7` | `2001:db8::7/128` | A single IPv6 address is a range of one. |
| `203.0.113.0/24` | `203.0.113.0/24` | A CIDR range stays as you typed it. |
| `10.1.2.3/8` | `10.0.0.0/8` | The platform normalizes the range to its network address. |
Rules that apply to the list:
* Use CIDR notation for ranges. The platform does not accept "from-to" ranges such as `203.0.113.1-203.0.113.50`.
* Duplicates are merged. `203.0.113.5` and `203.0.113.5/32` are the same entry.
* The whole list, joined by commas, cannot exceed 200 characters. Prefer ranges over long lists of single addresses.
## The three states of the list
***
| State | What it means | Is access restricted? |
| ---------------------- | -------------------------------------------- | ---------------------------------------- |
| **Empty** | No entries. | No. |
| **Saved, not applied** | Entries exist, but no switch is on. | No. The list is stored and does nothing. |
| **Active** | Entries exist and at least one switch is on. | Yes, on the surfaces you switched on. |
The Console shows the current state in a banner at the top of the IP allowlist tab. You always know whether the list is enforced.
## How fast a change applies
***
A change applies to the next request. The platform reads the list and the caller's address on every request, so there is no waiting period.
This also means a token does not keep access alive. A person or system that already holds a valid token is refused on its next request if its address is no longer on the list.
## Safety behaviors in the Console
***
The Console protects you from the most common mistake: locking yourself out.
* Before the first entry activates the list, the Console asks you to confirm.
* If your own address is not on the list, the Console warns you before it saves.
* An **Add my IP** button adds the address you are connected from.
* The Console asks for a separate confirmation before it applies the list to API access.
Read the step-by-step guide in [Managing the IP allowlist in the Console](/en/platform/access-manager/features/ip-allowlist/console).
## What the allowlist does not cover
***
* **Lerian's own platform services keep working.** Requests that carry a platform-internal token bypass the list, so your workspace does not stop by accident.
* **There is no administrator exemption.** An administrator who connects from an unlisted address is refused like anyone else. Keep at least one address you control on the list.
* **Break-glass.** If every administrator is locked out, contact Lerian support to restore access.
## Next steps
***
Add addresses, choose where the list applies, and deactivate it.
Read and replace the list with two Identity API operations, with examples.
What a BYOC operator configures so the platform learns the caller's real address.
Every code the allowlist can return, with title and message.