Trust center

Clear controls. Firm boundaries. No borrowed trust marks.

This page explains the product controls we can describe today and the claims we deliberately do not make. A provider logo, a polished interface or an encryption icon is not evidence of certification; where proof is not public, we say so.

Privacy notice Acceptable use

Our position

Trust starts with a statement that can be checked.

SpicyAPI shows each model’s supported inputs, current availability, pricing and policy boundaries in the product. Users choose the model they want to call, and accepted tasks receive traceable identifiers. We do not present planned controls as completed audits or treat a third party’s certification as our own.

What happens to what you send

Your prompts and outputs never become our training data.

We do store them, for a window that ends. Claiming otherwise would be disproved by one screenshot of our own console, so here is the version that survives scrutiny: what is kept, what it is used for, and the one limit we cannot engineer away.

Read the privacy policy

Kept, then erased: Prompts, free-text parameters and result references sit in the task record for 30 days, and then those fields are cleared. The row stays, because it is the only record of what you were charged. After erasure it is a few hundred bytes and holds no content.
Not training data, not for sale: SpicyAPI does not use your prompts, uploads or outputs to train any model, and we will not start without asking you separately and explicitly. We do not sell or rent personal data. Beyond our own systems, the model service that executes your request processes that input under its own terms — a boundary the privacy policy sets out, not one we can promise away on its behalf.
No advertising, no cross-site tracking: Three cookies exist: one keeps you logged in, one protects forms against cross-site request forgery, and one from Google Analytics measures traffic on the website. Its advertising features and Google Signals are switched off, and it never receives your account, prompts or outputs.
Counts, not free text: Before a prompt is erased we keep a few signals about it: character count, writing system, how many reference files were attached, and a one-way digest of the parameters. No free text is in that set, and the digest cannot be turned back into values.

The limit we will not paper over

To produce a result, the model service running your request needs your prompt in plain text. No arrangement in which we forward that request can make it unreadable to everyone but you, so we do not claim end-to-end encryption and we do not make promises on behalf of terms we did not write.

Retention

Every class of data has a clock. Three of them are yours.

The periods below are maximums, read from the running configuration rather than chosen to fill a document. Generated files, prompt text and uploaded references can each be set shorter than the figure in the table — never longer, because these are the numbers the storage rules themselves enforce. A legal hold can make a record live longer; your own settings are the only thing that makes one go sooner.

Up to 30 days

Prompts and result references

A maintenance job clears both fields from the task record. Set the clock shorter and the same job runs to your date instead. Two interlocks sit inside it either way: a task under a legal hold is never cleared, and neither is one whose usage signals have not been extracted yet.

Up to about 14 days

Generated images, video and audio

Storage removes expired objects on its own schedule, typically within a day of the expiry point. Shorter settings use our cleanup sweep, which normally runs within minutes; the stated period remains approximate rather than a promise of deletion at an exact second.

Up to 1 day

Reference files you upload

The upload URI stops working at its expiry. Object deletion can follow up to 24 hours later, and that lag does not extend how long the file can be used. Set uploads to go as soon as the job using them finishes and there is no lag to speak of.

90 days

IP address and user agent

Then replaced in place with a keyed hash — in login sessions, security events, policy acceptances and the audit log alike. That is pseudonymisation, not anonymisation: the hash is stable, so two records from the same address still match. The address itself is gone from the row and cannot be read back.

35 days

Database backups

Data you deleted stays in encrypted backups until they rotate out. During that window it is used for nothing and is excluded from any restore.

Years

Billing and audit records

Ledger entries are append-only — the database role that runs the service cannot update, delete or truncate them — and are kept for as long as US tax and accounting law requires. Audit records are kept for two years, and only a verified continuous prefix of the chain is ever removed.

Three limits are stated the same way in the privacy policy: deletion is not instant, the ledger is not erasable, and an active hold outranks a deletion request.

Your settings

Shorter, on your terms. Gone, on your word.

A retention period you cannot change is a disclosure. These four are controls: three clocks you set, and one call that ends a piece of work early. Every one of them only ever shortens the life of something — nothing here can extend it past the table above.

Three clocks, set separately: Generated files, prompt text and uploaded references answer three different questions, so they are three settings rather than three notches on one dial. Each applies to your whole account, and a single request can go shorter still by sending one header. The lowest of the three figures wins, so a stricter account setting is never talked out of it by a request.
The default is the loosest setting: New accounts start at the maximum, exactly where the platform has always sat. Tightening is something you choose, with the consequences spelled out beside each option before you save. A privacy control that quietly loses somebody's reference file on their second day is not a privacy control.
References that do not outlive the job: Uploads can be set to go the moment the task using them reaches a final state — finished, failed or cancelled, not the moment it was submitted, because a retry needs the file. The trade is real and we would rather state it: running the same reference again means uploading it again.
Destroy a finished task yourself: One call removes that task's outputs, its stored result and its prompt text. There is no review step and nobody to ask; asking twice is not an error. Afterwards the task reads as destroyed by you, which is a different sentence from expired — we are not going to let our own housekeeping take credit for your decision.

What destruction deliberately leaves alone

The billing record. The amount, the date, the model, the request ID and the state the task ended in all survive, because that row is what a disputed charge is settled from, and a balance you could edit by deleting history would be worth less than one you cannot. Destruction removes the content, not the receipt.

What it does not reach

Destruction leaves billing records and encrypted backups subject to their stated retention periods, and cannot remove files someone has already downloaded. The task is marked as destroyed when cleanup is scheduled; physical deletion follows in the background, normally within a minute. The task record shows when file deletion is still pending.

Credentials

Assume a key will leak. Bound it before it does.

A key handed to a contractor should be able to do less than the one your own backend uses. Every limit below is set per key, editable afterwards, and decided inside the transaction that creates the task rather than reconciled the next morning.

Key limits in the terms

Shown once, stored as a hash: The full key appears one time, right after you create it. Only a hash is kept, so nobody can read a lost key back out. It can be revoked and replaced, and that is the whole repertoire.
Three ceilings, each independent: A daily cap, a monthly budget and a lifetime cap, each set by you. The daily cap is the one worth setting first, because it stops a stolen key before you have read the alert. Money held for tasks that have not settled still counts against the budget.
Model list, IP allowlist, expiry date: A key can be limited to named models, to specific source addresses, and to a date after which it stops working on its own. Leave a list empty and that dimension is unrestricted, which should be a decision rather than an oversight.
Revocation lands on the next request: Calls made with that key are rejected from then on. Tasks already accepted keep running and are still charged, because acceptance is the point of no return. The key’s last-used time and address are shown, so you can see whether it was used before you noticed.

Keys carry operational limits only. There is no content entitlement to grant or withhold: what a model will produce is a property of the model you selected.

Our own systems

The parts you cannot check from outside.

Retention windows and key limits you can verify from your own console. These you cannot, so they are written down here in the form we would have to answer for.

The operations console is a separate service: It runs as its own process, on its own hostname, behind its own tunnel and its own access layer. The public service does not register those routes at all, so there is no administrative path to find from the API host.
No inbound port on the origin: Every service reaches the internet through an outbound tunnel, so there is no open port to scan for. The origin re-checks that a request genuinely arrived through the edge before anything else runs, and answers a failed check with a bare 404 instead of a diagnostic.
Money moves only by hand: A top-up, an adjustment or a refund is an immutable request carrying its own payload hash and expiry, actioned by hand by an administrator inside a console that is a separate service behind its own access layer. Owning an account does not include the ability to move its funds.
Administrative actions are hash-chained: Each entry carries the hash of the one before it, so a removed or edited entry breaks the chain. No endpoint writes or deletes an audit entry, and the database role that runs the service cannot update or delete one either.

What this is not: an independent audit. A chain we verify ourselves shows that our own records are internally consistent. It is not a third party’s signature and we do not present it as one.

Disclosure register

What is visible—and what is not claimed.

Published in the product

Model availability, input schema, unit price, task state, billing records, request identifiers, policy summaries and a dated changelog. These are product disclosures, not third-party assurance.

Not claimed here

SOC 2, ISO 27001, PCI DSS, HIPAA eligibility, independent penetration-test coverage, a contractual uptime SLA, universal data residency or universal zero retention. On availability we publish a target rather than a guarantee: 99.9% for our own layer — request intake, task intake and callback delivery — with live component status at status.spicyapi.ai. A target earns no service credits, refund or other compensation, and it excludes the third-party model services that execute a generation. Silence must not be read as certification.

Operational transparency

Published product information separates current availability, task state, pricing and content rules from certifications or guarantees. Rely only on commitments that are stated as current and applicable.

When something is wrong

One address, a person at the other end, and no scanning in between.

Requests are not reviewed one at a time. What exists instead is a reporting channel, a preservation step that begins after a report or a legal notice, and an appeal read by someone other than whoever decided first.

Open the reporting page

support@spicyapi.ai: Prohibited content, privacy requests and legal notices. Describe the problem and send the task or request ID; never attach the material itself. For sexual content involving a minor, skip the form and put CSAM ESCALATION in the subject line — those are handled ahead of everything else.
support@spicyapi.ai: Accounts, billing, and a task that failed without its held amount coming back. Writing in is not the only route: the console exports your own data as JSON, destroys a finished task's content, and can close the account outright.
Security research: A machine-readable contact is published at /.well-known/security.txt. Probing access controls, rate limits or billing needs written authorisation through that channel first, and there is no bug-bounty programme to point you at.

Target handling times

One business day to acknowledge a report you left an address on, three business days for the escalation route, ten for everything else. Privacy requests are answered without undue delay and within whatever period the law that applies to you sets for them.

These are targets, not guaranteed response times. Availability is a target too, not a commitment: there is no service level agreement and no service credits unless one is signed separately.

Policy boundary

Creative latitude does not remove consent or law.

When a customer uses an uncensored model, every depicted person must be an adult and have documented consent. Content involving minors, non-consensual intimate imagery, deceptive use of a real person’s likeness or voice, exploitation, or material unlawful in the relevant jurisdiction is prohibited. These duties remain with the customer; the Acceptable Use page states the rules and the Privacy Notice explains the associated data handling.