An NSFW image API that renders the prompt your code sent

Keys are minted in the console and travel as a Bearer token. One endpoint opens a job: name the model, hand it the prompt, add whatever that model takes. What comes back is an identifier, not a picture — the socket closes immediately, because a thirty-second render held inside an HTTP request is a timeout waiting to happen and every integration that tried it learned the same lesson.

From there you ask about the job rather than wait on it. A plain GET against that identifier answers with where the work stands: still queued, mid-render, done, or failed. Your process can die and restart between those calls without losing anything, since the job belongs to the server and not to the connection that opened it.

One habit is worth forming early: ask the catalog endpoint what exists instead of writing model identifiers into a constants file. That endpoint is what the site itself renders from and what the ledger bills against, so it moves the instant anything changes. A hard-coded list does not move, and you find out weeks later through a rejected call naming a dimension that was retired. Each model's own page reads from that endpoint as well and shows the id to send with the sizes and costs it accepts: the Seedream API, Qwen image API and MiniMax H3 image API pages are three of them.

Every image model in the catalog reads both ways: a prompt alone generates from scratch, and adding one or more reference images switches that same model id to editing instead. There is no separate editing-only id to look up and no text-only id that declines an attachment by mistake.

References travel through their own endpoint first. Send the file, keep the address it hands back, and name that address when you open the job. Anyone holding the address can fetch it without a session, and that is deliberate: the machine doing the rendering lives outside your account and still has to read the bytes.

Throttling is counted per account, and the rejection tells you the number of seconds to hold off. That figure exists so your retry logic can read it, which is a different design goal from a log line a human squints at after the fact.

The ledger moves at the start of a job rather than at its end, since that is the moment the work gets commissioned. What follows from that is the part automated callers should care about: a job that dies inside the provider hands its credits straight back when it lands in the failed state. Nothing to file, nobody to email.

Nothing about pay-as-you-go credits renews on their own — an optional monthly plan is the one exception, and you choose it. A service that fires twenty calls one week and none the next pays for twenty calls if it sticks to prepaid credits, because there is no floor underneath them. Every package buys credits at the same rate, and a package buys balance and nothing else — no key is faster, no key reaches models another key cannot.

If you are weighing the fal.ai API, the Replicate API or ModelsLab for adult image work, the comparison that matters is not a feature grid but what each one does by default, as its own documents put it on 12 September 2026. fal's published schema for its FLUX.1 [dev] endpoint sets enable_safety_checker to true; switching it off needs authorization on the account, a request without that authorization is always checked, and a flagged image comes back black. ModelsLab's text-to-image reference likewise defaults safety_checker to true and swaps a flagged picture for a blank one, while its terms of service, dated 24 June 2023, hold only a general clause against illegal or harmful use and nothing written about adult content as such.

The policy documents diverge further than the parameters do. Novita's Acceptable Use Policy, in force since 5 August 2026, lists sexually explicit output among prohibited uses and describes no opt-in for adult work. Replicate's terms, last updated 1 April 2026, rule out non-consensual nudity and illegal sexual material, and section 8.6 states outright that the services can generate graphic adult content, with responsibility for it resting on the customer. Read those clauses before writing integration code, since they decide what that platform permits. Venice AI's image API, with its own safety default, is read against ours in the Venice AI alternative.

Billing is shaped differently as well. ModelsLab sells monthly plans that vary by call volume and concurrency rather than by which models you may use; fal's model page advertises no subscription or minimum commitment and prices that image model per megapixel; Novita is pay as you go and charges per image on the image models we read. Vellria sits nearest the last two: a prepaid balance, a per-image credit price listed on each model's page, and nothing that renews unless you choose one of its two optional monthly plans.

What Vellria lacks, stated as plainly. There is no SDK, so an adult image API call here is plain HTTPS with a JSON body from whatever language you write. The image and video endpoints are not OpenAI-compatible, so an OpenAI client will not drive them by swapping the base URL; the one OpenAI-compatible endpoint is chat, for the Uncensored Chat model. There are no outbound webhooks; you learn how a job ended by polling. If one of those is a requirement, Vellria is the wrong fit for that part of your stack; and if the requirement is weights you run yourself, open-source NSFW models or a hosted API sets out what that route costs.

Nothing rewrites the prompt, and the space that opens up is genuinely wide — fictional adult work included. Some things stay shut regardless of key, balance or endpoint: identifiable real people who never agreed to appear, and the categories the terms rule out even in fiction, such as bestiality, incest, non-consent and extreme gore. Cross that line and the account goes, keys with it.

The automatic checks do not look for ordinary real people. The prompt check refuses a prompt it recognizes as sexualising a minor and keeps no list of famous names, so a well-known person is not caught either. Reference images are not screened for content: no picture is refused for who or what it shows, and there is no image_blocked refusal on this path. So the rule on ordinary real people is one to enforce inside your own product; the API will not detect it for you. The page on what an NSFW AI image generator allows carries the policy in full, and the API reference has the request bodies, status codes and error shapes. For clips rather than stills, the NSFW video API takes the same keys and the same polling.