Skip to main content
In this lab we’ll place a rate limiter in front of an API and observe it enforce a limit of 10 requests per minute. The limiter identifies clients using an identifying header in these examples (X-Client: me). You can verify limits by sending repeated requests and inspecting the response headers for rate-limit metadata and HTTP status codes.

Quick test

Send this request repeatedly to exercise the limiter:
If the request is within the allowed quota you’ll receive a successful 200 response and rate-limit headers similar to this:
  • X-RateLimit-Limit — the number of allowed requests per minute (10).
  • X-RateLimit-Remaining — how many requests remain in the current window.
If you exceed the configured quota (more than 10 requests within the minute), the limiter rejects additional requests with an HTTP 429 (Too Many Requests). A typical rejection response:

Response headers explained

How the limiter identifies clients

This lab uses the X-Client request header to identify each client. If your environment uses a different identifier — for example, client IP, an API key, or an authorization token — replace the header accordingly when testing.
Be aware the limiter in this example identifies the client using the X-Client header. If your setup uses client IP or another identifier, adjust your test accordingly. The Retry-After header (when present) indicates the number of seconds to wait before retrying.

Troubleshooting & tips

  • If you see unexpected behavior, confirm the header is included in your request exactly as configured (header names are case-insensitive, but values must match the expected client ID).
  • Use curl -v to view full request/response details for debugging.
  • When testing from shared IPs (e.g., CI runners or NATed networks), be aware that IP-based identification can group multiple users under the same limit.
  • If you need a different rate window or quota, adjust the limiter configuration in the deployment or proxy that enforces the policy.

Watch Video

Practice Lab