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

# IP Restrictions

> Restrict your team's API keys to an allowlist of IP addresses or CIDR ranges, so they only work from approved networks. Enforced server-side.

IP Restrictions let your team maintain an allowlist of IP addresses and CIDR ranges that API requests must originate from. The allowlist is enforced server-side during authentication on every authenticated request, so a leaked or exfiltrated API key is useless outside your approved networks.

The allowlist is team-scoped: it applies to all of the team's API keys at once.

<Note>
  IP Restrictions are an enterprise feature and are gated per organization. Contact your Firecrawl account team to have them enabled for your account.
</Note>

<Note>
  This is the *inbound* control — where your requests to Firecrawl may come from. If you are looking for the *outbound* direction (static egress IPs for Firecrawl's traffic to your systems, so you can allowlist Firecrawl), see [Enterprise features](/enterprise).
</Note>

## What you can allowlist

Entries can be:

* **Single IPv4 addresses** — e.g. `203.0.113.7`
* **Single IPv6 addresses** — e.g. `2001:db8::1`
* **CIDR ranges**, IPv4 or IPv6 — e.g. `10.0.0.0/8`, `2001:db8::/32`

Clients connecting over IPv4-mapped IPv6 (`::ffff:203.0.113.7`) are normalized to their IPv4 form before matching, so an IPv4 entry covers them.

The allowlist is enforced only when it is **non-empty**. An empty allowlist means no restriction, so a team can never lock itself out before it has configured any IPs.

## Configuring the allowlist

Team admins manage the allowlist from [Enterprise Controls → IP Restriction](https://www.firecrawl.dev/app/enterprise-controls?tab=ip-restriction) in the dashboard. Add or remove entries and save — changes take effect within about a minute.

## Enforcement

The check runs during authentication, so it covers every authenticated surface uniformly: all API versions, job status and cancellation endpoints, and websocket status connections. There is no request-level way to bypass it.

A request from an IP that is not on the allowlist is rejected with a `403`:

```json theme={null}
{
  "success": false,
  "error": "Request blocked: IP address 198.51.100.24 is not on this team's allowed IP list. Team admins can manage allowed IPs at https://www.firecrawl.dev/app/enterprise-controls?tab=ip-restriction"
}
```

## Error reference

| Status | When                                                                                                                           |
| ------ | ------------------------------------------------------------------------------------------------------------------------------ |
| `403`  | The request's IP address is not on the team's allowlist.                                                                       |
| `500`  | The allowlist could not be verified. Requests fail closed (are rejected) rather than bypassing the restriction. Retry shortly. |

## Notes

* IP Restrictions add no credit charges.
* IP Restrictions are independent of [Key Restrictions](/features/key-restrictions); a team can use both, and a single key can be limited by format, endpoint, and origin network at the same time.