Authentication

Public APIs use your application's own GloopAPI key. Keep keys on your server or in secure local environment variables; do not put them in web pages, repositories, shared links, or logs.

Request identity

Authenticate requests with Authorization: Bearer $GLOOP_API_KEY. Send the key in the request header to keep it out of URLs. Model lists always use the OpenAI format.

The key, account, and model/tool authorizations jointly determine access. Another key on the same account is not the original task identity: historical tasks, tool runs, and files generally require the same account and key. Model permissions do not automatically grant tool permissions; tool execution uses the intersection of the account group's permissions and the key's tool authorizations.

Ordinary and persistent reads

Ordinary text, synchronous images, speech, model catalogs, and audio cloning use ordinary authentication. When quota is exhausted, audio clone status or result queries may also be rejected; retrieving results is not guaranteed.

Persistent image, video, tool run, and file routes use their corresponding persistent authentication, allowing still-valid keys with exhausted quota to query history. Expiration, revocation, IP restrictions, and account bans still cause rejection. New generation also requires budget, permissions, configuration, and capability checks; being able to read history does not mean you can create tasks.

Image history still checks current model permissions. Checks for video history and request recovery vary by path; this does not justify claiming that all historical reads apply the complete generation policy. Refer to each endpoint's authentication description.

Files and signed URLs

Use the original key to retrieve API file metadata and download URLs. A short-lived signed download URL itself grants read access. Do not share it publicly or forward the API key to object storage. Image asset content supports Bearer or server signatures; when signature parameters are present, only signature validation is used, with no fallback to Bearer on failure.

For 401, check the key and its expiration; for 403, check the account, IP, and permissions. Fix the cause before proceeding. Reconcile unknown submissions using the recovery procedure; do not generate duplicate results by switching keys.