Disney API · Rate Limits

Disney Rate Limits

Disney API (disneyapi.dev) is a free, unauthenticated REST and GraphQL service for Disney character data, maintained by a single open source contributor (ManuCastrillonM) and historically hosted on Heroku. The provider does not publish per-key, per-IP, or per-account request-rate limits in the project README or on the disneyapi.dev documentation site. The README explicitly calls out that infrastructure costs are paid out of pocket by the maintainer and invites donations via a Support Us page, so consumers should treat the API as best-effort and apply client-side caching, batching, and exponential backoff to avoid exhausting the maintainer-funded infrastructure budget.

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

It captures 3 rate-limit definitions, measuring requests_per_second and varies.

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

Tagged areas include Rate Limiting, Entertainment, Characters, and Open Source.

3 Limits Throttle: 429
Rate LimitingEntertainmentCharactersOpen Source

Limits

Documented per-key request rate key
requests_per_second
not documented — service does not issue API keys or publish per-account rate limits
The provider does not publish numeric request-rate limits. Plan for best-effort access and degrade gracefully on 429 / 5xx.
Platform-level Heroku dyno caps account
varies
bounded by the maintainer-funded Heroku dyno tier
The upstream service is hosted on Heroku and underwritten by a single open source maintainer. Throughput is effectively bounded by the dyno tier and MongoDB plan the maintainer is paying for, not by any provider-declared rate-limit policy.
Edge / proxy abuse mitigation IP
varies
enforced opaquely by upstream platform
Excessive request rates from a single source IP may trigger upstream platform protections (challenge pages, 429s, or temporary blocks) independently of any provider-defined limit.

Policies

Cache aggressively
The character dataset (9,820+ records) changes very slowly. Clients should cache entire pages — or the full corpus — locally and refresh on a daily or weekly cadence rather than refetching on every read.
Apply client-side throttling
Because no published limits exist, consumers should self-throttle (e.g. 1 request per second per client) and avoid burst patterns that could destabilize the donation-funded backend.
Use exponential backoff on 429 / 5xx
On HTTP 429 or 5xx responses, back off exponentially before retrying. The API has no Retry-After header and no remaining-budget header to consult, so blind backoff is the safest strategy.
Prefer pageSize boundaries that match upstream
Default pageSize is 50. Honor the default unless your workload benefits from a larger page; very large pageSize values increase memory pressure on the upstream dyno without saving roundtrips relative to using paging plus client-side caching.
Support the maintainer
The project README explicitly invites donations to underwrite hosting costs. Commercial consumers depending on the API should consider contributing via the Support Us page so the service remains available.

Sources