A Static IP for Zapier
Zapier includes a static IP feature on its Professional, Team and Enterprise plans, and Zapier's own documentation describes it as “a consistent IP address that all of your Zapier traffic is guaranteed to come from”. If you are on one of those plans, that is your answer and it is included in what you already pay. This guide is for the two cases it does not cover: you are on Free or Starter, or you need the same source address for Zapier and for systems that are not Zapier.
Why Zaps do not have a fixed address by default
Zapier runs on shared cloud infrastructure and provisions capacity as it needs it. An outbound call from a Zap — a webhook, a custom request, an API action — leaves from whatever address that infrastructure has at that moment. There is no small published range to allow-list, and a range that covered it would cover a very large amount of other traffic.
This bites in a specific and confusing way: your Zap works for weeks, then a vendor turns on IP filtering, or your Zap starts failing intermittently because some calls leave from an address on the list and some do not.
Zapier's own answer, and when to just use it
The static IP feature is on Professional, Team and Enterprise. Two details from Zapier's documentation that decide whether it fits:
- It does not cover every app. Zapier lists the apps it supports for static IP. For a public app that is not on the list, you are asked to contact their support to request it; for private apps, you enable it by contacting support.
- It does nothing on Free. Zapier states directly that if you are on the Free plan and add their listed addresses to your allow-list, your traffic will not be routed through a static IP. Adding the addresses does not enable the feature — a genuinely easy mistake that produces an allow-list which looks right and does not work.
If you are already on Professional or above and your app is supported, use Zapier's static IP. It is included, there is nothing to run, and nothing on this page is better than a feature you have already bought.
Check the direction of the problem first
Half the people asking this question do not need a static outbound IP at all, because the traffic they are worried about is going the other way. Be precise about which of these you have:
- Zapier calling out to a vendor who filters by source address. That is the outbound problem this guide is about.
- Zapier calling in to your own API, which you have put behind an IP allow-list. Here you control the receiving end, so you have better options than IP filtering: require a shared secret in a header, check a signature, or — as Zapier suggests — allow requests carrying the
User-Agent: Zapierheader. A header check you control beats an address list you do not.
If it is the second one, fix it at your own API and stop here. It is free, it is stronger, and it does not break when infrastructure moves.
When an address you hold is the better answer
Two cases, both narrow and both real.
You are on Free or Starter and upgrading is not worth it. If the only reason to move to Professional is this one integration, compare the plan difference against a dedicated address attached to a small box you route that one call through. Sometimes the upgrade is still better value — you get the rest of the plan too. Do the arithmetic rather than assuming.
You need one address for more than Zapier. This is the one that decides it most often. If the same vendor must also accept calls from your backend, a scheduled job, or a colleague's machine, Zapier's static IP covers exactly the Zapier half. A dedicated address from 23.187.152.0/24, announced by AS396500, is one allow-list entry that covers all of them, and it stays the same if you move off Zapier entirely.
Honest caveats, the same ones as everywhere on this site:
- It is a hop and a machine you keep running. Zapier's feature has neither. On a no-code platform chosen precisely so you do not run servers, that is a serious argument against this approach.
- It suits named calls, not “everything my Zaps do”.
Verify the source address before you file it
Do not send the vendor the address you configured, and do not send them Zapier's published list unless you have confirmed the feature is actually on for your plan and your app. Send the address the far end really sees. The quickest honest test is a Zap step that calls a service which echoes the caller's address:
curl -4 https://api.ipify.org
Point a Webhooks by Zapier request at https://api.ipify.org, run the Zap, and read what comes back. Run it several times — on shared infrastructure one observation tells you about one invocation, not about the next. A mis-filed address fails as a total denial at the vendor's end, not as a warning.
What this costs with us
A dedicated address is $20/month on TunnelNet Full, inbound and outbound on the same address, attached to a machine you already have. TunnelNet Business is $100/month for the same address with a written 8-working-hour response commitment (09:00–17:00 US Central, Monday to Friday), onboarding done with a person who verifies the source address from outside our network before you file it, and our measured uptime published — incidents included.
Plainly, because you are about to put a partner integration on this: we have no SLA and will not offer one until we have six months of measured history, 21 February 2027 at the earliest. A hub failure that withdraws routes takes about 25 seconds to recover, measured — and a hub that stays up while it stops forwarding is not failed over automatically at all. Zapier will quote you better availability numbers than that, and they will be true. Weigh it against what the address itself is worth to you.
Static IP for your platform
The same question, answered for each platform it comes up on most. Every one of them leads with that platform's own native or free answer:
- AWS Lambda — VPC and NAT Gateway, and what that really costs
- Vercel — $100/month per project, and Vercel documents the IPs as shared
- Netlify Functions — no list exists — what to try before building anything
- Supabase Edge Functions — Supabase documents that there is no static egress IP
- Heroku — Private Spaces, proxy add-ons, or an address you hold
- Render — shared by default, genuinely dedicated on Pro
- Railway — a Pro-plan toggle, and the “may be shared” caveat
- GitHub Actions — larger runners, or the free self-hosted answer
And the general case, if your platform is not listed: