which vendors let you allowlist them

slash0 fetches and parses the official range publications of every service in its catalog, continuously, and republishes them as a signed feed. Doing that means writing a parser per vendor and then living with the result: the pages that get restyled, the files with no cache headers, the ranges that appear one morning with no warning. This page is the byproduct of that work. It is not a survey of vendor documentation, it is a record of what it takes to track each one in production.

Nothing here is a judgement about the services themselves. A vendor can be excellent and still publish its ranges badly. What is being measured is narrow: whether an automated consumer can follow your ranges without heroics.

what the score measures

Five points, one for each thing that separates a range list you can automate from one you have to babysit.

1. Machine-readable source. The ranges come from an endpoint that returns structured data. The alternative is a documentation page, which means every consumer writes a scraper and every scraper breaks on a redesign.
2. Cheap change detection. The server honors conditional requests, so checking for a change costs a 304 rather than a full download. Without it, following a vendor closely means refetching the entire list on a timer.
3. Purposes separated. The publication distinguishes what the ranges are for, so allowlisting the API does not also allowlist every other thing the vendor operates. The common failure is one flat list covering an entire company.
4. Advance notice. The vendor documents how long a newly published range sits unused before it starts carrying traffic. This is the single most useful thing a vendor can offer, and it is the rarest.
5. A change signal. Something the vendor operates that tells you a change happened: a notification topic, a status page subscription, a version endpoint. Polling is the fallback when this does not exist.

findings

• 66 services publish official ranges. 38 state that you should not pin them at all. Between them the 66 publish 30,136 CIDRs, rebuilt continuously and republished as a signed feed.
• 1 of 66 scores five out of five. Only Elastic Cloud does everything on this list.
• 9 of 66 commit to any advance notice before newly published ranges start carrying traffic: Auth0 (Okta CIC), Buildkite, CircleCI, Databricks, Elastic Cloud, LaunchDarkly, Microsoft 365, Microsoft Azure (Service Tags), Stripe. For everyone else, a range can go live the moment it appears.
• 8 of 66 operate a change signal you can subscribe to (Amazon Web Services, Atlassian Cloud, CircleCI, Elastic Cloud, Fastly, LaunchDarkly, Microsoft 365, Stripe). Another 4 are trackable only because their documentation happens to live in a public git repository, so the commit feed stands in for a notification the vendor does not offer.
• 28 of 66 have no machine-readable endpoint at all. Their ranges exist only inside a documentation page, so every consumer writes a scraper and every consumer breaks when the page is restyled.
• 20 of 66 honor conditional requests. The rest have no cache validators, so checking for a change means downloading the whole list again.
• 10 of 66 publish one undifferentiated set. Allowlisting the API also allowlists everything else the vendor runs, including infrastructure that has nothing to do with your integration.
• 43 of 66 publish no IPv6 ranges. Reported in the table but left out of the score, since a vendor with no IPv6 footprint has nothing to publish.

the table

Sorted by score, then alphabetically. Every cell is read from the feed, and every service name links to its page, where the current ranges render live. Advance-notice and change-signal entries link to the vendor page that states the claim, so any cell can be checked at its source.

IPv6 is reported but not scored. A vendor with no IPv6 footprint has nothing to publish, and penalising that would measure their network, not their publication practice. The same reasoning keeps range count out of the score: a large list is a fact about a vendor's size.

the vendors who decline

These services state that IP allowlisting is unsupported or unreliable for them, and most name what to do instead: verify webhook signatures, allow a hostname, use a private endpoint. That is a legitimate answer, and it is more useful than a list that quietly goes stale. They are published in the feed under nonPublishers so that tooling can tell "no ranges exist" apart from "no ranges found".

method

Every row comes from the published feed at feed.slash0.io/v1, which is rebuilt from each vendor's own publication and carries the source URL and a hash of the upstream body it was derived from. The registry behind it, including the evidence link for every non-publisher, is public in sources.yaml. Advance-notice entries record only periods the vendor documents; a vendor that announces changes without committing to a lead time scores nothing on that criterion, which is a deliberately strict reading. Every notice period and every change signal in the table was read from the vendor's own page and links back to it. Those pages are also submitted to the Internet Archive, so a vendor reorganising its documentation cannot leave a claim here unsupported.

Two caveats worth stating. Notice periods are counted only when they cover the ranges published here: PagerDuty commits to 30 days for its REST API addresses, for example, but not for the webhook sources in this catalog, so it scores nothing for notice. And a low score reflects how a vendor publishes, not how good the service is.

Corrections are welcome, particularly from vendors. If a range publication changed, or this page has something wrong, get in touch and the registry gets updated.

The feed and the Terraform provider that reads it are free. The quickstart is two data sources and a security group rule.