FAIRVISORFair usage enforcement for your API, without writing enforcement code
Per-tenant rate limiting from JWT claims. Noisy neighbor protection. Tiered plans. Kill-switch for abuse. All declarative, all at the edge, with low-latency decisioning.
What Fairvisor Does for API Platforms
Claims-Based Rate Limiting
Limits based on JWT claims (org_id, plan, user_id) — not IP addresses. Your auth system defines the identity. Fairvisor enforces the limits. No coupling.
{
"match": { "jwt:plan": "free" },
"limit": "free-tier"
},
{
"match": { "jwt:plan": "pro" },
"limit": "pro-tier"
}
Named Limits (DRY)
Define limits once, reference them everywhere:
{
"limits": {
"free-tier": { "algorithm": "token_bucket", "rps": 50, "burst": 100 },
"pro-tier": { "algorithm": "token_bucket", "rps": 500, "burst": 1000 },
"enterprise": { "algorithm": "token_bucket", "rps": 5000, "burst": 10000 }
}
}
All Must Pass Composition
Multiple rules can apply simultaneously. A request must pass all matching rules:
- Rate limit per org (50 RPS)
- AND rate limit per user (10 RPS)
- AND daily budget ($100/day)
- AND loop detection
No code. No if-else chains. Declarative.
Noisy Neighbor Protection
Each tenant is isolated by their own counters. One org hitting their limit doesn’t affect any other org. Ever.Abuse Response: Kill-Switch
Fast containment for any tenant or route, with role-gated operations and audit logging.AI Crawler Throttling
AI bots (GPTBot, ClaudeBot, Meta-ExternalAgent) scrape your public/docs and API references at scale. Fairvisor detects them by User-Agent, applies separate rate limits (e.g., 10 RPS), and shows you how much bandwidth they consume. Your real users aren’t affected.
Shadow Mode for Safe Rollouts
Deploy new rate limits in shadow mode. See what would be blocked on your real traffic. Tune. Then enforce.Decision Tracing for Fast Incident Response
When traffic is rejected, teams can trace from 429 to reason/retry headers, then use debug-session headers for policy/rule attribution.Works With Your Existing Gateway
Don’t rip and replace. Fairvisor integrates as a decision service:
- Nginx:
auth_request - Envoy:
ext_authz - Kong: custom plugin
- Traefik:
forwardAuth
Or run it standalone as a reverse proxy.
Per-Route and Per-Partner Overrides
Keep global tier limits, then add precise overrides for sensitive endpoints or premium partner integrations. Shared defaults stay clean while edge cases are explicit and auditable.Before / After
| Before Fairvisor | After Fairvisor |
|---|---|
| Rate limiting code in every service | One policy file, enforced at the edge |
| IP-based limits (who is 10.0.3.42?) | JWT claim-based limits (org_id: acme_corp) |
| 30 min to find which tenant is abusing | Kill-switch runbook for rapid containment |
| “We’ll add rate limiting later” | Shadow mode → enforce in one deploy |
| Pro tier customers see 503 from Free abuse | Tenant isolation by default |
Integration Options
Kong
Custom plugin. Install, configure, deploy. Compatible with Kong Gateway OSS and Enterprise. → Kong guideStandalone reverse proxy
No existing gateway? Run Fairvisor in front of your service directly. → Standalone deploymentDecision service (sidecar)
Prefer your existing ingress? Fairvisor runs as anauth_request-style decision service alongside it. → Deployment options
Who This Is For
- B2B SaaS products with tiered API plans (Free / Pro / Enterprise)
- Multi-tenant platforms where one customer’s abuse affects others
- Teams with rate limiting scattered across multiple microservices
- API-first companies where enforcement gaps cause customer incidents
FAQ
Can I set different rate limits per pricing tier?
Yes. Match on JWT claims likeplan: free, plan: pro, plan: enterprise and apply named limit definitions. One policy file covers all tiers — no per-service implementation per tier.
How do claims-based limits work?
Fairvisor reads JWT claims from the request token and matches them against policy rules. Your auth system defines identity; Fairvisor enforces limits based on it. No coupling between your auth service and rate limiting code.What happens when a tenant hits their limit?
Staged response: warn header at 80%, throttle (added delay) at 95%, 429 withRetry-After at 100%. Each tenant has isolated counters — one tenant hitting their limit doesn’t affect any other tenant’s experience.
How quickly does the kill-switch take effect?
Propagation is designed to be fast and should be validated in your deployment environment. Actions are role-gated (Operator or above) and audit-logged with operator identity, reason, and scope.Does Fairvisor work with my existing API gateway?
Yes. Integrates as a decision service:auth_request (Nginx), ext_authz (Envoy/Istio), custom plugin (Kong), forwardAuth (Traefik). Or run standalone as a reverse proxy. No rip-and-replace required.
What is shadow mode?
Shadow mode enforces nothing but logs what would have been throttled or rejected on your real traffic. Deploy it first, see what your traffic would hit, tune your limits, then enable enforcement. → Shadow mode rolloutCan multiple rules apply to one request?
Yes. “All must pass” composition: a request must pass every matching rule. Rate limit per org AND per user AND daily budget AND loop detection — all enforced simultaneously from one policy file.How do I debug why a request was rejected?
Start with reject headers (X-Fairvisor-Reason, Retry-After, RateLimit*). For policy/rule attribution, enable debug session headers (X-Fairvisor-Debug-*). → Decision tracing
Why teams choose Fairvisor
One policy file, enforced everywhere
Declarative limits replace custom enforcement code scattered across microservices — no more per-service implementations that drift apart.Limits that map to actual customers
JWT claim-based enforcement means limits followorg_id, not 10.0.3.42. Your auth system defines identity; Fairvisor enforces consequences.