rate-limiting

Implement hierarchical rate limiting with IETF-standard headers for multi-tenant SaaS APIs.

3|2|Updated Jan 23, 2026
One-click install
npx skills add https://github.com/robotijn/ctoc --skill rate-limiting-robotijn
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rate-limiting
Source: https://github.com/robotijn/ctoc/tree/main/skills/saas/rate-limiting
Command: npx skills add https://github.com/robotijn/ctoc --skill rate-limiting-robotijn

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Unprotected SaaS APIs are vulnerable to brute-force credential attacks, distributed denial-of-service (DoS) incidents, noisy-neighbor resource starvation on multi-tenant platforms, and abusive bot traffic, leading to service outages, data breaches, and unfair resource consumption for legitimate users.

Core Features & Use Cases

  • Hierarchical rate limiting: Enforce layered limits at global, per-tenant, per-user, and per-IP scopes to prevent noisy neighbors and NAT abuse, with fail-closed behavior for sensitive authentication endpoints.
  • IETF-compliant response semantics: Emit standard RateLimit headers and proper 429 Too Many Requests responses with Retry-After values to enable well-behaved clients to self-throttle without hitting limits.
  • Algorithm and tooling guidance: Select the right rate-limiting algorithm (sliding window, token bucket, etc.) for your use case, with implementation examples for FastAPI, Spring Boot, .NET, Next.js, and common tools like Upstash Ratelimit, slowapi, and Bucket4j.
  • Use case example: A multi-tenant B2B SaaS platform can use this skill to implement per-tenant caps that prevent one customer's runaway batch job from consuming all shared API capacity, while also blocking credential-stuffing attacks against login endpoints.

Quick Start

Use the rate-limiting skill to implement hierarchical per-tenant and per-IP rate limits for your SaaS API with proper IETF headers and brute-force protection for authentication endpoints.

Frequently Asked Questions about rate-limiting

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I implement rate limiting for a multi-tenant SaaS API to prevent noisy neighbors?

Implement hierarchical rate limiting to enforce layered caps at global, per-tenant, per-user, and per-IP scopes. This prevents noisy-neighbor resource starvation by ensuring one customer's batch job cannot consume all shared API capacity.

How does distributed throttling work with Redis for API rate limiting?

Distributed throttling uses Redis or equivalent distributed state to track request counts across multiple server instances. This enables consistent sliding window or token bucket enforcement for multi-tenant SaaS platforms regardless of which node handles the request.

What's the best way to configure brute-force protection for authentication endpoints?

Apply fail-closed rate limiting behavior to sensitive authentication endpoints. Layered limits at per-IP and per-user scopes block credential-stuffing attacks while allowing legitimate login attempts.

Does this rate limiting approach work with FastAPI, Spring Boot, and Next.js?

Yes, this skill provides algorithm selection and implementation examples for FastAPI, Spring Boot, .NET, and Next.js. It integrates common tools like Upstash Ratelimit, slowapi, and Bucket4j across major web frameworks and cloud runtimes.

How do I return proper 429 Too Many Requests responses with standard RateLimit headers?

Emit IETF-compliant RateLimit headers and proper 429 Too Many Requests responses with Retry-After values. This enables well-behaved clients to self-throttle without hitting limits repeatedly.

When should I use sliding window versus token bucket algorithms for API throttling?

Select rate-limiting algorithms based on use case: sliding window for strict per-tenant caps on developer APIs, token bucket for burstable web traffic. Match the algorithm to high-cost operations like AI inference or bulk exports.