GIFs.so currently limits authenticated requests to 120 per minute and 20,000 per day per account, using fixed UTC windows. The allowance is shared across browser usage, REST, MCP, and all API keys on the account.
Creating another key does not create another allowance. Plan your application around how people use the picker rather than around the number of GIFs returned in one response.
Count the requests users generate
Typing can create many searches before the user selects anything. Category browsing, pagination, and item lookups add more. Failed calls also consume rate-limit capacity, and repeating a request with the same requestId does not avoid the rate limit.
Recorded usage is a separate concept: one successful search, lookup, or category operation counts as one request in analytics, regardless of how many items are returned. Request-ID deduplication affects those records; it is not a quota bypass.
Use a moderate page size and avoid refetching item details when the search response already contains everything your preview needs. Debounce text input and discard stale requests.
Handle 429 as a wait state
Stop issuing immediate retries when the API returns 429. Respect retry information if the response provides it; otherwise apply a bounded delay with jitter and wait for the relevant window to reset. A daily limit will not be resolved by waiting a few milliseconds.
Show a useful message in the picker and retain already loaded results. Avoid clearing the whole grid just because the next page was limited.
Limit your own clients too
A server proxy protects a secret key, but an open proxy can still let strangers consume the account allowance. Authenticate callers and add application-level per-user limits where appropriate.
Coordinate automated jobs with interactive traffic. A background catalog experiment can consume the same allowance that a user needs for a live picker. Read usage through the documented endpoint rather than inferring success from attempted call counts.
Monitor the right symptoms
Track 429 responses, timeouts, searches per selection, and repeated identical calls. These reveal whether the problem is real demand, inefficient UI behavior, or a retry loop.
The integration guide is the current source for limits. Read retry and idempotency guidance before adding automatic recovery, and caching guidance before assuming that another provider permits the same optimizations.