A GIF API key authorizes requests; it should not be distributed to every browser that opens your app. For a web picker using a shared account key, place the provider call behind your server and protect that server route with your application’s own access rules.
GIFs.so requires a verified account. Creating an account and possessing a key do not remove the email-verification requirement.
Use the documented credential channel
For REST, send the key in the x-api-key header. Create keys in your account settings after verification. Store them in the server environment or your deployment’s secret store, and avoid including them in URLs where they can enter browser history or routine logs.
Keep client and server environment variables distinct. In frameworks that expose specially prefixed variables to the browser, a secret must not use that public prefix. Minification and obfuscation do not protect a shipped credential.
Protect the proxy as well as the key
An unauthenticated endpoint that forwards arbitrary search requests can turn your private key into a public resource indirectly. Require the intended application session, validate query length and page size, and apply per-user controls appropriate to the product.
Forward only the provider operations your frontend needs. Do not create a general-purpose URL proxy or let the browser choose arbitrary upstream hosts and headers.
Log operation names, statuses, and request identifiers without logging credentials. When reporting an error, redact both headers and any old query-string keys.
Treat access failures as actionable states
A 401 should lead you to check whether the key is present, valid, and associated with verified access. It is not a transient failure to retry repeatedly. Separate that case from 429 limits and 503 availability failures.
If a key leaks, revoke it through the account controls and replace it in the legitimate server environment. Creating another key does not increase the account’s request allowance.
MCP uses its own authorization flow
GIFs.so’s remote MCP endpoint uses OAuth 2.1 with PKCE and documented scopes. Follow the client’s authorization flow rather than pasting a key into a prompt or inventing an unsupported transport configuration. GIF tools need read access.
Use the integration guide and llms.txt as the current authority. The REST vs MCP guide explains which surface fits a traditional application and which fits an assistant-driven workflow.