JSONPlaceholder · Rate Limits

Jsonplaceholder Rate Limits

JSONPlaceholder does not publish or document any rate-limit numbers. The service is a free best-effort offering that handles roughly three billion requests per month without per-IP or per-key throttling. CDN-level protections may apply at the edge but are not documented. Consumers should treat the service as best-effort: do not rely on it for production traffic, do not build dependencies on tight latency SLAs, and back off if you start receiving 5xx responses or your traffic is identifiably abusive. For guaranteed behavior, self-host json-server (the same open-source engine).

Jsonplaceholder Rate Limits is the machine-readable rate-limit profile for JSONPlaceholder on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 2 rate-limit definitions, measuring varies.

The profile also includes 4 backoff/retry policies defined and response codes documented for serverError and notFound.

Tagged areas include Rate Limiting, Development, and Fake API.

2 Limits
Rate LimitingDevelopmentFake API

Limits

Documented rate limit IP
varies
none documented — best-effort public service
typicode does not publish per-second, per-minute, or per-day request caps. The service is intentionally permissive for tutorials, demos, and classrooms.
Edge / CDN protection IP
varies
undisclosed CDN-level abuse protection may apply
A free public service of this scale is generally fronted by a CDN that will throttle obviously abusive patterns (very high concurrency, bot traffic). The thresholds are not published.

Policies

Treat as best-effort
JSONPlaceholder is a free community service. Consumers should not depend on it for production traffic. If you need guaranteed availability or throughput, self-host json-server locally.
Back off on 5xx
If the service returns 5xx responses, apply exponential backoff with jitter. Do not hammer the public endpoint.
Avoid abuse patterns
Do not use JSONPlaceholder as a backend for a real product. Do not run high-concurrency load tests against the public endpoint — run them against a self-hosted json-server instead.
Writes are simulated
POST, PUT, PATCH, and DELETE return success-shaped responses but do not persist. If your client retries a write, the second response will look identical to the first — there is no idempotency key surface because there is no real persistence.

Sources