An internal or partner API does not need to answer the whole internet. It needs to answer your developers, wherever they happen to be working today. The edge is the right place to enforce that, if the allowlist can keep up with people who move.
APIs that are really for a known group, internal tooling, an admin API, a partner integration, usually sit fully public anyway, guarded by a key. A leaked key then works from anywhere. The natural hardening is to default-deny at the edge and allowlist your team's IPs, but developers roam: office, home, a hotel, a client site. A static edge allowlist is wrong within a day, so someone gets locked out, or the rule quietly gets left wide.
Enforcing at the edge, your CDN or WAF, means hostile traffic never reaches your origin in the first place. The bytes are dropped upstream, which is exactly where you want to absorb scanning and abuse. Pairing an edge IP allowlist with the API key turns one factor into two: an attacker now needs both the key and a packet sourced from an approved IP. The hard part was never the deny; it was keeping the allow current without a human in the loop.
Each developer is a named pair, bundled into one access group. A cron polls the group's live IP list every couple of minutes and rewrites the edge allowlist, your CDN or WAF rule for the API hostname, replacing the set so it never accumulates stale entries. A dev moves networks, clicks one bookmark, and their new IP is allowed at the edge within the poll window. To everyone whose IP is not in the group, the API simply does not answer.
This is the pattern we run ourselves. The IPAuth API sits behind NOC, our CDN and WAF, default-deny, with the developer group driving the allowlist. The same script shape swaps cleanly for Cloudflare rulesets, a cloud security group, or any edge with an allowlist API. Onboarding a dev is adding a pair to the group; offboarding is removing it, and the edge follows on the next sync with nothing to hunt down by hand.
Best for APIs with a known, roaming set of human or team-operated callers where you control the edge. If your API must serve anonymous public clients, an IP allowlist is the wrong tool; rate limiting and per-key scoping are. But for an internal, admin, or partner API that should be invisible to everyone but your team, edge allowlisting driven by a roving group gives you a second factor that maintains itself.
Put your devs in one group and point the edge sync at its IP endpoint.