How we moderate

SpicyAPI generates adult content for consenting adults, and nothing else. This page describes the controls that run on every request, in the order they run. The rules themselves are in the Acceptable Use Policy.

1. No uploads, by design

The API never uses an uploaded photo as an image or video input. The only images that can be edited, inpainted, upscaled or animated are images previously generated by the same account, verified server-side against a registry of outputs before anything is charged. A picture sent to the reference image model is screened, described in words without identifying facial features and discarded; a new image is drawn from the description, so the photo never reaches the image model. Apart from character import below, a real photograph cannot become part of an output, which is what keeps non-consensual imagery made from someone's photo off SpicyAPI.

The one exception is character import, for registered businesses moving their own platform's AI-generated characters to SpicyAPI. Only a paying account that proves a mailbox on the platform's own domain can apply, with its certificate of incorporation and a recent list of directors; we check them against the company's registry record, its website and the Internet Archive, and a named director signs a separate Character Import Agreement, with a drawn signature from a link sent to their own email. The window lasts a week, is capped, and can be switched off at any time. The customer attests on every import that the images show fictional, AI-generated adults, and names the page on its own website where each character is published: we look for the image there and in the Internet Archive. Every uploaded image goes through the same output screen as generated images before anything is rendered; files carrying camera metadata are refused as photographs; every photorealistic character is searched for elsewhere on the web (whole images, never faces) and held until a person approves it, as is anyone who looks young; and a single blocked upload switches import off for the account and flags it for review. Uploads never become inputs themselves: they are re-rendered into a character reference sheet, and we review imported characters and what is generated with them.

2. Prompt screening, three layers

Every prompt for image, edit and video generation passes through a keyword blocklist, contextual pattern rules (distress, incapacitation, age-evasion phrasing, references to named private individuals, attempts to instruct the safety system), and a semantic classifier that returns a probability for each prohibited category: apparent minors, real identifiable people (including lookalikes), non-consent, bestiality, gore and prompt injection. It reads the prompt in any language.

Borderline declines get a second opinion before anyone sees them: when a decline comes from a wording rule or an uncertain score, a separate model re-reads the prompt against the whole policy and the request goes through only if it is clearly allowed and shows no age or real-person risk. Clear violations are never re-read.

A stated adult age (18 or older) is accepted, unless the prompt also asks for a younger look, describes a child's body, or places the subject in a school or childhood setting; those are always refused. Allowed prompts whose wording still leans young are logged for daily human review. Other categories block at high probability and return a review outcome at moderate probability, which asks the user to reword so that subjects, ages and consent are explicit. If the classifier is unreachable the request fails with a 503 rather than proceeding unscreened. Blocked and reviewed prompts are never charged.

The screen also sees the requester's last few declined prompts, so a reworded, translated or obfuscated retry of something already refused is judged as a pattern, not as a fresh prompt. Because an API account is usually a platform serving many people, that history is kept per end user when the developer sends a user id with the request, and per account only when they do not. Any prompt that has ever produced a withheld image is refused outright, for every account, before a model runs.

3. Output image review

After an image is generated it is reviewed by a vision model before it is returned or stored as a reusable asset. Images that appear to show a minor or a recognisable real person are deleted, withheld from the response, refunded, and logged. If the review itself cannot run, the image is withheld and refunded rather than delivered unreviewed. Withheld images are hashed so the same bytes are never delivered again, and the prompt that produced them is blocked. Video tasks the model itself refuses come back with error_code: "blocked" and are refunded.

4. Chat

Chat completions are screened as a conversation, including the system prompt, so a persona that is presented as under 18 is caught even when each message looks innocuous. Role-play between fictional adult characters may depict non-consent, framed as consensual or not, and other dark themes; minors, real people, incest and strangulation are declined in chat as everywhere else. As with generation, an unreachable screen means a 503, not an unscreened reply. Messages that suggest a user may be at risk of self-harm are not blocked; they are flagged in the response (x-spicyapi-safety: self_harm) so that companion apps can route the person to support.

5. Account strikes

Blocks in the severe categories (minors, real people, non-consent, bestiality) count as strikes. In chat, fictional non-consent between adult characters is allowed; only non-consent against a real person, or presented as real, is declined and counts. When requests carry a userid, strikes accrue to that end user, who is refused after ten; the developer is told which user, and their account is flagged for review rather than suspended for a customer's behaviour. Without a user id, strikes accrue to the account: flagged after three, suspended after ten. Only the semantic screen's refusals in those categories are strikes (keyword refusals, refusals a second opinion overturned and withheld outputs are not), and strikes do not expire. Flagged means a person here reviews the account; the API keeps working and nothing is suspended or charged because of the flag. POST /v1/moderations never records a strike; dry runs and sandbox keys run the real screen, so their refusals count like any other. At signup, developers describe what they are building; products that would require prohibited content are held for review before an API key goes live. Any decline can be reported as wrong, from the playground or by sending its moderation_id to POST /v1/moderations/appeals; we review it, and confirmed mistakes change the screening rules.

6. Evidence and retention

Every block, review, output withholding and classifier outage is recorded with the account, the prompt, the category probabilities and the time. Cleared requests keep their category probabilities on the request log. These records are retained for the period stated in our Privacy Policy and are what we produce to law enforcement on a valid request.

7. Reporting and takedown

Anyone, customer or not, can report content through our report form or by email to contact@spicyapi.com, with links and a screenshot, even without knowing whether we made it. Reports are classified on receipt and matched against our records: links are traced to the files we host, and pictures are compared by fingerprint with the characters customers have imported. Reports concerning a minor or a real person start a 48-hour removal clock, alert our team at once, and suspend anything we can match while we review it. A takedown deletes the file from our CDN and permanently bars it from being used as an input, while the record is kept as evidence.

Not affiliated with spicyapi.ai

SpicyAPI is operated by Wayfinity Ltd at spicyapi.com, and only there. We are not affiliated with spicyapi.ai or any other service using a similar name. Those services are not bound by the controls described on this page. In particular, SpicyAPI does not accept photographs of real people and does not offer face swap, head swap or character swap. If you have seen content attributed to "SpicyAPI", check which service produced it before reporting it to us; reports about spicyapi.com content go to our report form.

For developers

Screening errors carry a machine-readable code, outcome and per-category categories so your product can tell users what to change. You can also run the same screen ahead of time with POST /v1/moderations, or pass dry_run: true to any generation endpoint to get the price and the screening result without generating. Our 2257 statement and transparency report are public. See Errors & limits.