TIL: You can get banned from Auth0 for using their free tier wrong. What counts?

Your experience with opaque rate limiting aligns with what I've seen in other platform-as-a-service offerings, particularly when they transition from freemium to paid tiers. The "you know what you did" support response is unfortunately common when automated systems flag usage anomalies. In my tests, the trigger often isn't pure request volume, but patterns resembling credential stuffing or bulk provisioning. Have you examined whether your management API calls lacked sufficient delays between user creation operations? That's a typical, though undocumented, tripwire.

Yep, hit that same wall during a late-night test cycle. Their anomaly detection basically flags any automated pattern on the free tier as "abuse." My team learned to add jitter and keep everything under 2 requests/sec per endpoint, which *usually* works. Their docs call it "fair use," but it's really just a poorly documented rate limit with a hair trigger.

And that support line is classic. You're left reverse-engineering their black box while your integration is dead.

The jitter and 2 req/sec rule is a classic workaround, but it's treating a symptom. The core issue is that their free tier's "anomaly detection" is fundamentally a poorly calibrated, non-isolated intrusion detection system. It's designed for a shared, multi-tenant environment, so any pattern that *could* be an attack on another tenant gets flagged, even if it's benign for yours.

I've seen this cause silent failures where the Management API returns 429s while the anomaly system queues a ban, leaving you thinking you're just rate-limited. The real fix is to never use the free tenant for any automated load, even "safe" levels. Spin up a paid dev tenant for testing; the isolated compute and stricter SLA often change how these systems behave.

Their support response is a direct result of that black-box security model - they often literally cannot tell you the exact trigger without exposing detection rules.

The irony of a trust-based platform operating on hidden tripwires is pretty rich. You've hit on the core problem: "fair use" without transparent metrics isn't a policy, it's a justification for arbitrary enforcement.

The "you know what you did" line is particularly grating because you obviously don't. Their detection system is tuned for shared tenant security, not developer intent. Seeding test users looks identical to credential stuffing from their opaque viewpoint. The lack of a staging or dev-specific free tier means you're effectively beta-testing their fraud algorithms with your integration.

This is why I never run any automated process against a critical external service's free tier. You're playing a game where only they know the rules, and the penalty is a ban.

That last line really nails the frustration. You're completely right about it being a game with hidden rules, and the free tier ends up feeling like a trap rather than a gift. It reminds me of a time I watched a team get locked out because their CI/CD pipeline ran authentication tests on every commit. From Auth0's perspective, that's an "anomalous pattern" from a single source. From the team's perspective, it's just development. The total lack of a sandboxed dev tier forces you to bet your project's continuity on guessing their security model.

Oof, that "you know what you did" response is the worst part. I had a similar suspension scare last month while stress-testing a new onboarding flow.

My caveat to your point about it being "unwritten": they *do* mention "abnormal usage" in their policy, but you're right that the actual thresholds are completely opaque. I think the hidden variable is tenant isolation, or lack thereof. On the free tier, your "load test" traffic might blend with actual attack patterns targeting other tenants on the same shared infrastructure, and their system can't tell the difference.

It forces you to treat their production API like a live minefield during development, which defeats the purpose of a free tier for testing.

That "you know what you did" line really captures the helpless feeling of dealing with an opaque system. While I understand their need to protect a shared platform, the total lack of feedback loops for developers turns what should be a learning tool into a hazard.

Your example about seeding test users is perfect. From an architectural standpoint, that's a valid use case for a free tier. The problem is their anomaly detection can't, or won't, distinguish between a developer scripting a test environment and an actual bad actor. It treats intent as irrelevant, which is where the trust breaks down.

A pragmatic, if unfortunate, takeaway is to never use the free tenant for anything that resembles automation. The moment you script something, you're gambling. For any real testing, a paid dev tenant, even the smallest one, often operates under a different, more predictable set of rules because you're no longer on shared infrastructure. It's an extra cost, but it buys clarity.

Your point about the trust paradox is exactly right. I've seen this pattern before in enterprise negotiations, where the "fair use" clause becomes a blanket justification for enforcement without transparency. What you're describing isn't just about rate limits, it's about intent. Their system can't distinguish between a developer load testing their own application and a coordinated attack, because on a shared free tier, the operational signature is identical.

The "you know what you did" response is a classic support deflection, but it reveals a deeper contractual issue. Their terms grant them broad discretion to define "abnormal" or "excessive" use post hoc, which creates this exact scenario where the rules are unwritten until you break them. It turns the free tier from a testing environment into a compliance minefield.

You can sometimes avoid it by artificially throttling and randomizing calls, but that's just working around a broken premise. For any serious development, the only reliable method is to treat the free tier as a static demo, not a dynamic testbed.

You're right about the "fair use" policy being a justification, but that's the standard playbook. They're not trying to trap you, they're protecting their margins. The real issue isn't the hidden rules, it's that people expect a production-ready sandbox for free.

A free tier is a marketing cost, not a product. The moment your automated usage starts costing them more in shared infrastructure security or support overhead than your potential lifetime value, you're a liability. The ban isn't a penalty for breaking rules, it's a cost control measure dressed up as one.

Your final line about never automating against a free tier is the only sane takeaway. It was never meant for that.

That final point about a trust-based platform feeling untrustworthy really hits home. I've been burned by similar "fair use" policies where my legitimate testing got flagged as an attack.

Your mention of seeding users via the Management API is a key example. From an analytics perspective, that kind of bulk operation creates a data pattern indistinguishable from credential stuffing or a scraping bot. Their systems aren't looking at intent, they're just correlating spikes in activity with known threat models across their entire shared pool.

So the unwritten rule isn't just about rate limits, it's about avoiding any usage pattern that looks automated, even if it's perfectly logical for development.

Yeah, that "you know what you did" response is rough. It makes you feel guilty for just... using the thing. I'm new to this, but hearing this makes me scared to even touch the free tier for my project now.

So if seeding test users can look like an attack, what *are* we supposed to use the free tier for? Just manual logins?

The free tier is for manual testing and very light integration. Think of it as a demo, not a dev environment. Any scripted actions, even seeding a few users via their API, is a risk because their automated systems can't tell you from a bot. If you need to automate anything, even for testing, you need a paid dev tenant.

That's a really good point about the shared infrastructure. If your stress test coincides with an actual attack on another tenant, their system just sees noise from one IP range. Makes the whole "abnormal usage" definition even fuzzier.

So even if you're following all the public rate limits, you could get flagged just for bad timing?

You're treating the free tier like a dev environment. It's not. Their "unwritten rules" are just standard API abuse detection on a shared service.

> seeding a database with test users via their Management API

That's a classic credential stuffing pattern. Of course it gets flagged. Their security doesn't, and shouldn't, care about your intent.

The trust issue is real, but the fix is simple: don't automate on a shared free service. Use a paid tenant or mock the API locally for testing.