Allowed IPs (IP Allowlisting)

Lock down API and web-dashboard access to your account so it only succeeds from IPs you’ve explicitly trusted. Requests from any other IP are rejected with a clear ip_blocked error and the account owner is alerted by email the first time each new IP is blocked.

Plan-gated. This is an enterprise paid-tier feature. Trial users do not get IP allowlisting — by design, so trial accounts can’t accidentally lock themselves out. Available on plans where the admin has flipped the ip_allowlist_enabled flag.

Navigate to Settings → Allowed IPs.

What gets gated

Mobile is bypassed because cellular networks rotate IPs constantly and would lock users out within a day.

Add an IP address

Click Add IP Address and pick one of two modes:

Static IP

A single IPv4 address. The form pre-fills your current IP for one-click setup.

Office HQ        49.47.154.224

IP range

A start and end IPv4. Useful for office VPNs that hand out an IP from a small pool.

Mumbai office VPN     49.47.154.10  to  49.47.154.30

Each entry needs a friendly IP Name (max 80 chars) so you can identify it later — e.g. Office HQ, Home office, Production server.

When changes take effect

Allowlist changes propagate within ~60 seconds (the per-user cache TTL). Add an entry, wait a minute, the next request from that IP succeeds. Removing an entry takes the same window.

The allowlist UI itself is never gated by the allowlist — even if you somehow add only a wrong IP and lock yourself out, you can still reach Settings → Allowed IPs from the dashboard to fix it.

What blocked users see

API callers

Any /api/v1/public/* or /api/v1/graphql request from an IP not on the list returns HTTP 403:

{
  "success": false,
  "code": "ip_blocked",
  "ip": "203.0.113.45",
  "message": "Access denied — your IP address is not on this account's allowlist."
}

Rate-limit budget is not consumed by blocked requests, so a misconfigured client retrying in a loop can’t burn through your quota.

Dashboard users

The web app catches the ip_blocked response and replaces the page with a dedicated block screen showing the rejected IP and a Refresh / Log out option. No data ever loads on the blocked page.

Email alerts

The first time a given IP is blocked on a given day (UTC), the account owner receives an email:

Subject: Blocked login attempt from a new IP

Hi <name>,
We just blocked an access attempt from 203.0.113.45.
If you recognise it, add it from Settings → Allowed IPs.

Subsequent blocks from the same IP within 30 days are suppressed — no spam. After 30 days, a fresh block triggers a new alert.

Empty allowlist = no enforcement

If the feature is enabled on your plan but you haven’t added any entries yet, enforcement is off. We treat an empty list as “everyone allowed” rather than “nobody allowed” so users don’t accidentally lock themselves out by toggling the feature on without configuring it.

The first entry flips on enforcement immediately. Until then, every IP is allowed.

Limits

• Up to 50 entries per account (mix of single IPs + ranges).
• IPv4 only today. IPv6 ranges are on the roadmap.

API errors and how to fix them

Mobile bypass

The Splashify Pro mobile apps and any custom client using the Expo SDK identify themselves with an X-Platform header (ios / android / mobile / expo). The IP gate short-circuits when this header is present so users on cellular networks aren’t locked out by a rotating mobile IP.

The bypass is not exposed on the public API — sk_live_… keys, SMTP credentials, and GraphQL Bearer tokens are all gated regardless of headers.

Best practices

• Audit your list quarterly. Old VPN exit IPs, decommissioned offices, and rotated cloud build agents accumulate quietly.
• Use ranges sparingly. A /24 is fine for a stable office network; a /16 defeats the purpose.
• Pair with team-member-level permissions so even users on the right network only see what they should.
• Keep the mobile app installed as a fallback — if you mistype an IP and lock yourself out, you can still reach the dashboard from the mobile app to fix it.