Flickr · Rate Limits

Flickr Rate Limits

Flickr enforces request-rate throttling per API key. Limits are not aggressively published, but the long-standing documented guideline is 3,600 queries per hour per non-commercial API key, with commercial keys reviewed and adjusted on a case-by-case basis. Excessive request rates can result in the key being temporarily or permanently throttled. There is no formal sandbox environment; all calls hit api.flickr.com. Burst patterns and abusive usage are addressed via Flickr's API Terms of Use, not via a public rate-limit HTTP header.

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

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

The profile also includes 6 backoff/retry policies defined and response codes documented for throttled, throttledLegacy, invalidKey, and badRequest.

Tagged areas include Rate Limiting, Photography, Photos, and Developer API.

4 Limits Throttle: 429
Rate LimitingPhotographyPhotosDeveloper API

Limits

Per-key queries per hour (non-commercial) key
requests_per_hour · hour
3600
Long-standing documented guideline for non-commercial keys. Flickr may temporarily throttle keys that exceed this; sustained abuse can revoke the key.
Per-key queries per second (burst) key
requests_per_second · second
1
Practical burst guidance derived from the per-hour limit; Flickr does not publish a hard per-second number.
Per-key queries per hour (commercial) key
requests_per_hour
negotiated with Flickr
Commercial keys may have a higher ceiling; the exact number is set during the commercial review process.
Photo upload throughput key
varies
subject to per-key hourly cap and per-file size limits
Uploads count against the per-key hourly cap. Per-file size caps are enforced at the upload endpoint (`https://up.flickr.com/services/upload`).

Policies

Exponential backoff
Clients receiving a 429 or 503 should back off exponentially before retrying. Flickr does not publish a specific backoff curve; treat 503 as a transient-throttling signal.
One key per application
Each distinct application MUST use its own API key. Sharing keys between applications is grounds for revocation and skews per-key throttling decisions.
Identify your app
Flickr's TOS asks that all requests include identifying parameters (the API key, optionally a User-Agent that names your application) so abusive callers can be isolated without affecting compliant ones.
Commercial use requires permission
Any commercial use of the API requires a commercial API key approved by Flickr. Throttling and quota terms for commercial keys are negotiated as part of approval.
No public quota / remaining headers
Flickr does not document `X-RateLimit-*` style response headers. Clients should track their own request rates locally rather than relying on server-returned remaining-quota signals.
Push subscriptions vs polling
For change-driven workloads, prefer the PubSubHubbub push API (`flickr.push.*`) over high-frequency polling — push subscriptions do not count toward the per-key hourly cap once established.

Sources