IP Restrictions are an enterprise feature and are gated per organization. Contact your Firecrawl account team to have them enabled for your account.
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.
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
::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 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 a403:
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; a team can use both, and a single key can be limited by format, endpoint, and origin network at the same time.

