> I use VPNs because I don’t trust rando open WiFi hotspots or the ISPs that serve them. I frequently still buy things over the VPN and stay logged in with accounts attached to me.
So what? If our service gave you that clear error message that we don't accept VPNs — well, you would have the perfectly-viable option of just waiting until you get home to register. It's not the sort of service you register for "in anger" with any kind of urgency. It's a B2B data-analysis API, only relevant for companies and professionals; and it's one that you need to spend hours exploring and reading the docs of to get real use out of, because "real use" almost always consists of calling multiple endpoints, graph-walk-wise, to explore data relationships.
Also, as it happens, we don't consider "invited by a team member" to be a registration; coming in through an invite link doesn't go through any of the checks. (This is because we've yet to actually see a promotion-fraud attacker who has ever taken advantage of the teams system. Probably they assume all accounts in a team will be rate-limited together at the team level, even though we've never said anything to that effect.)
So if you're working for a company that has chosen to use our API, and you're not the one person in your company who was tasked with initially evaluating our API, but rather are just someone who needs to actually use it — then you'll do that by receiving an email, clicking on the magic link, and filling out your details; and all of that will work just fine over your VPN on the rando open WiFi hotspot. Because "clicking on an invite link" is distinguishable from promotion fraud.
It's only if your traffic is indistinguishable from promotion fraud — if it fits the signature of promotion fraud — that we'll block it. And that signature, right now, for us, is:
1. sends traffic from a colo, VPN, or Tor exit-node IP address;
2. uses an email address where the domain is either:
2a. from a "temporary inbox service";
2b. from one of a few common mail services which do not themselves speed-limit registrations (Microsoft / outlook.com is bad for this; Rambler.ru is another. Perhaps surprisingly to any cypherpunks in the audience, ProtonMail isn't in this set — so they're fingerprinting you somehow to enable that!):
2c. freshly-created (<2d old);
2d. has an MX record whose zone's NS record indicates that their MTA is hosted on a cheap colo (you'd think this would generate false positives, but it's very unlikely on the modern web, as an MTA on such a box would have too low a reputation to send mail, so nobody would bother unless the MTA is only for receiving, i.e. is a one-off temporary email proxy-host);
3. uses an email address where the username is either:
3a. "gibberish" — indistinguishable from keyboard-mashing (see https://pypi.org/project/gibberish-detector/);
3b. generated by combining census-data-list names with 4+-digit number suffixes, with the former to make the address look real, and the latter to ensure a low change of collision at time of address registration;
4. specifies a user name, organization name, and/or API-key label (all free-text fields) as either gibberish, or mail-merged repetitions of the name in the address. (Real people who don't want to fill these out say something petulant here, rather than keyboard-mashing.)
5. matches the browser fingerprint of a previously-detected multiple-incident attack. (We do client-side browser fingerprinting, only for the registration page, to catch people who use e.g. Puppeteer + Zyte Smart Proxy Manager to automate registrations; but who don't realize that the Puppeteer Stealth plugin exists. Which is, surprisingly, a lot of people.)
These are all just factors in your registration "credit score"; you have to trigger multiple of them to get denied by our accounts backend.
We only start putting IPs into blocklists (thus making it into, in a sense, a single-factor denial) once we've actually seen attacks coming from these IPs. But we do investigate each such attack; and if the offending IPs all came from some "dedicated-bare-metal unmetered-bandwidth machine host" that nobody's ever heard of + exists as its own ASN + has no claim on its website to be policing its customers for abusive behavior (or worse, doesn't even have a website!)... then it's time to block that entire netblock, and every other netblock owned by the ASN, and every other ASN owned by the company. Every time we haven't before, the attacks just come back.