Civitai API Guide: Models, Images, Downloads and Authentication

Public reads may work without a key, but authenticated requests are more reliable and can access resources tied to your account permissions. Generate a key on the Civitai Account page and send it as a bearer token.

Do not hard-code a token in shipped browser JavaScript, public repositories, shared URLs, analytics events, or logs. An app that accepts each user’s own key can keep it in that user’s browser, but must disclose local-storage/XSS risk and may still need a transient proxy where authenticated CORS is unavailable. Use a separate named key for each integration so you can revoke one without disrupting the others.

The documented v1 REST surface includes creators, images, models, a single model, model versions, lookup by file hash, and tags. Model responses include creator, tags, statistics, permissions, versions, files, hashes, scan data, and example images when available.

The image endpoint supports filters such as model, version, user, maturity level, sort order, and time period. Returned generation metadata depends on what the uploader shared.

Use the smallest useful page size and apply server-supported filters. Read pagination metadata or cursor values from the response instead of guessing page URLs. Cache catalog responses when freshness requirements allow it.

Handle 401, 403, 404, 429, and 5xx responses separately. Retry only transient failures, add jittered backoff, and cap attempts. Do not retry an invalid key or missing resource in a tight loop.

Model-version records expose files and download URLs. Preserve the model ID, version ID, filename, and a strong hash beside the downloaded file. Verify that the response is the expected file rather than an HTML error page.

Respect creator permissions and Civitai terms. Avoid mirroring resources by default. Link to the source model page so users can review version notes and licenses.

klopaper searches Civitai media and LoRAs, resolves model-version resources, reads prompt metadata, and stages reusable text recipes. Civitai requests are authenticated server-side with klopaper’s own pooled token, so visitors never supply or store a Civitai key.

Generation is separate. klopaper runs the prepared recipe on its own hosted GPUs and debits your credits. Civitai remains the discovery and metadata source rather than the generation biller for those runs.