Comunicación de límites a los clientes de API

A limit that silently drops requests frustrates devs. A good API tells clients their usage, when they'll be throttled, and when to retry.

When a client exceeds its allowance, return 429 Too Many Requests — the universal signal that the request was throttled, not a server error.

Don't use 503 or 500 for throttling — they imply the server is broken. 429 is specific: the client's fault, and it's temporary.

Pair a 429 with a Retry-After header — seconds or an HTTP date — and well-behaved clients wait instead of hammering the server.

Add proactive headers on successful responses too, reporting remaining quota so clients self-throttle before they ever hit a 429.

Old APIs used X-RateLimit-*; the IETF draft uses unprefixed RateLimit-*. Pick one convention and document it — consistency beats the name.

The reset value is either seconds until the window resets or an absolute timestamp. Document which, or clients will retry too early.

Beyond headers, return a structured JSON error body with the limit, what's left, and a human-readable message to aid debugging.

Good clients read these signals and apply exponential backoff with jitter on a 429 instead of retrying instantly — Retry-After nudges them.

Document your limits, header names, and reset semantics. Predictable, published limits let integrators build resilient apps and cut support load.

The complete response: a 429 status, Retry-After, the RateLimit trio, and a descriptive JSON body — turning a rejection into guidance.

Status code, headers, error body — which signals actually tell clients about the limit?

Recap: throttle with 429 (not 5xx), add Retry-After, send RateLimit-Limit/Remaining/Reset so clients self-throttle, and document it all.