Hi everyone,
I’m working on a setup where an external application sends requests to a public API Workflow endpoint in Bubble.
For security reasons, I’d like to restrict access so that only requests coming from a specific (fixed) IP address are accepted.
My main question is:
Is there any way to capture the client’s IP address from the request headers inside a Bubble API Workflow?
Alternatively, is there any recommended approach to enforce IP-based restrictions for API Workflows in Bubble?
I’m aware of standard authentication methods (tokens, API keys, etc.), but in this case I’m specifically looking for an IP-based validation layer.
Any guidance or best practices would be greatly appreciated.
Thanks in advance!
Hey @lucaspsantos, welcome to the forum! Good question.
There’s a setting worth trying first: in your API Workflow, switch Parameter definition to “Detect request data” and tick “Include headers in the detected data” when you initialize it. That can expose request headers as normal workflow parameters, so it’s worth seeing whether anything with the real client IP comes through on your side.
That said, for real security I wouldn’t lean on headers alone — they can be spoofed by the caller, and Bubble doesn’t officially document which headers its infrastructure preserves. So the more solid pattern is to put a tiny proxy in front of your endpoint (a Cloudflare Worker or Vercel Edge Function works great). The proxy checks the real IP, rejects anything not on your allow-list, and then forwards good requests to Bubble along with a shared secret that your workflow validates. That way, even if someone finds your raw Bubble URL, they can’t bypass the check.
One last thing — IPs drift more than people expect (cellular, NAT changes, etc.), so I’d treat the IP check as a second layer and keep a strong bearer token as your main authentication.
Hope that helps — happy to go deeper on any part of it if useful.
Bubble doesn’t expose raw request headers (including X-Forwarded-For or similar) inside an API Workflow natively, so pure IP filtering isn’t really possible within Bubble itself.
A few approaches worth considering:
- Proxy layer — Route requests through something like Cloudflare Workers, AWS API Gateway, or an nginx reverse proxy before they hit Bubble. Filter by IP there, and only forward allowed requests to your Bubble endpoint.
- Shared secret + token — Since you control the external app, combine a static API key in the header with a time-based HMAC token. Not IP-based, but functionally gives you the same “only my server can call this” guarantee without the infrastructure overhead.
- Backend Agent (third-party) — Some builders use Make or n8n as a middleware that validates the source before relaying to Bubble.
Honestly, option 1 is the cleanest if you need true IP restriction. Cloudflare’s free tier can handle this with a simple firewall rule.
One question: is the external app something you fully control (i.e. you can add a shared secret to its outbound requests)? If so, a signed token is probably simpler than IP filtering and more robust if the source IP ever changes.
