When a partner asks you to allowlist an IP — and you deploy on Vercel

It arrives from a partner's security team: "for access to our production API, allowlist our IPs and send us yours." The first half is a firewall rule. The second half is where the week goes, because your application does not own an address.

Why there is no address to hand over

On Vercel, outbound requests from builds and functions leave through a dynamic range, and no published list of egress addresses exists to add to someone else's firewall. AWS Lambda behaves the same way once it is outside a VPC: the address belongs to the platform, not to your function. The same is true of Cloud Run without a connector, and of most edge runtimes by design.

This is not an oversight. It is what makes scale-to-zero possible: addresses are allocated from a shared pool as instances come and go.

Option 1: buy a static egress on your platform

Every large cloud sells the fix. On Vercel it is Static IPs — assign addresses per region and add them to the partner's allowlist; note that build traffic is separate from function traffic and needs enabling separately. On AWS it is a VPC with a NAT gateway and elastic IPs. On Cloud Run it is a Serverless VPC connector plus Cloud NAT.

• Pros: full control of the egress path; works for every partner.
• Cons: the NAT gateway is billed per hour plus per gigabyte, and it is a single point of failure you now own.
• Gotcha: addresses can change if you rebuild the stack unless they are held as reserved IPs.
• Gotcha: private data transfer pricing often applies to traffic that was previously free.

Option 2: pin the egress with a proxy or relay

Instead of moving the whole application into a VPC, route only the calls that need a fixed source through something that has one. That can be a self-run proxy on a small instance, a managed static-IP proxy, or an outbound relay.

The honest catch: the partner sees the intermediary's address, not yours. That is usually fine — it is still a stable, allowlistable source — but it means the allowlist no longer distinguishes between you and anyone else using the same relay. Pair it with a shared secret header and, better, an HMAC over the body so the partner can verify the request came from your account:

import { createHmac, timingSafeEqual } from 'node:crypto';

const timestamp = Math.floor(Date.now() / 1000).toString();
const body = JSON.stringify(payload);
// partner verifies: HMAC-SHA256(secret, timestamp + '.' + body)
const signature = createHmac('sha256', process.env.PARTNER_SECRET)
  .update(timestamp + '.' + body)
  .digest('hex');

const res = await fetch('https://api.partner.example/v1/orders', {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
    'x-timestamp': timestamp,
    'x-signature': signature,
  },
  body,
});

Option 3: get the allowlist removed

IP allowlists are weak authentication: they prove a network location, not a caller, and they break the moment you redeploy onto new infrastructure. Plenty of partners will accept a signed request over TLS plus a rotated API key instead, because it is stronger. Ask once, in writing, with the argument that an allowlist shared with every customer of a proxy is worth very little.

Option 4: move the call

Sometimes the cheapest fix is architectural: the partner's endpoint is called from the one place that already has a stable address — a scheduled worker, a queue consumer, a small always-on service — instead of from a request-scoped function. No new infrastructure, no new bill, and the call gets a retry policy for free.

What to tell the partner on day one

• The exact source addresses, with a note on which environments they cover.
• A shared secret and the signature scheme, so the allowlist is not the only control.
• What happens when the address changes — a rotation date, and a contact who announces it.
• Which endpoints you call, so they can scope the rule to a path rather than the whole API.

Whichever option you pick, write the decision down. The next engineer to hit this will start by asking the same question, and a one-page note is cheaper than repeating the research.