Trust and reliability
What runs your generations, what happens when one fails, and how long anything you send us lives. Every number on this page comes from an endpoint you can call yourself.
Right now
A probe runs every minute and the result is written down whatever it says, so a bad day stays in the record. The uptime numbers and the full daily history live on the status page.
Both feeds are public and need no API key: GET /health for the current state and GET /health/history for the per-day rollup. Point your own monitor at them if you would rather not take our word for it.
What the states mean
operational, degraded or down. The feeds expose the state and nothing else: no hostnames, no error text, no request counts.When a generation fails, you are not charged for it
The balance is debited when a generation is accepted, because that is when the work is committed. If it then ends in error or timeout, the charge is returned automatically. There is no ticket to open and nothing to reconcile at the end of the month.
- Every generation is bounded
- A generation carries its own timeout: fifteen minutes for most features, thirty for the long video ones, ninety for Voiceover, and two hours for Avatar Video, whose long scripts render far slower than real time. Nothing runs unbounded and nothing bills unbounded.
- Stragglers get swept
- A separate sweeper closes generations that pass their timeout without reporting back, so a worker that dies mid-render still resolves your generation and still refunds it, rather than leaving it pending forever.
- Load is shed, not queued forever
- Over your concurrency ceiling, submissions are refused with a 429 and a Retry-After rather than accepted into a queue that will time out later. You find out immediately, and you have not been charged.
- Delivery is not the source of truth
- Webhooks are best effort. The generation record is authoritative and always readable by id, so a delivery you never received is not work you lost.
The whole model, including every status and the webhook signature, is on How a generation works.
Money
- Prepaid, never invoiced by surprise. One balance for the organization. You cannot be billed for more than you have put in.
- The price is knowable first. GET /v3/pricing returns your exact rates, variants included, before you spend anything.
- Auto-recharge is yours to set. Off by default. When you turn it on, you choose the threshold and the amount, and you can remove the card at any time.
- Card details never reach us. Payments run through Stripe.
- Spend is inspectable. Every call is logged with what it cost, per project, in the app.
- Unspent balance is refundable. Ask within 60 days of a top-up and whatever you have not spent goes back to the card that paid for it. What you have already generated is not refundable, because it was delivered: the files are yours, without a watermark and with full commercial rights, and that cannot be taken back. Bonus balance was never paid for, so it does not convert to cash. A failed generation never enters this conversation, because it is refunded to your balance automatically the moment it fails.
Your data
Anything created through the API is ephemeral by design. That is a deliberate posture, not a limitation we have yet to fix: we would rather not be the long-term home for your customers’ faces and voices.
- Outputs: 24 hours
- A generation created through the API carries an expiresAt 24 hours out. After that the asset is reaped and the generation record itself stops resolving.
- Uploads: 24 hours
- A reference file you upload is deleted 24 hours after it lands, on the same clock, whether or not a generation used it.
- Deletion on demand
- DELETE the generation to remove it and its assets immediately rather than waiting for the expiry.
- Cloned voices persist
- A voice clone is the exception, because a resource you reuse is useless on a 24 hour clock. It lives until you DELETE /v3/voices/{id}, which destroys the voice itself and cannot be undone.
- App work is separate
- Work a person makes inside the app persists in their library. The 24 hour clock is on API traffic.
Consent and likeness
Generating a real person requires that person’s permission. The Terms of Use bind every account to that rule: generate a person only with their consent, or where the person is you, and never use a likeness to imply an endorsement they have not given. In the app, saving a person asks you to confirm exactly that before their photos can be used anywhere.
There is no separate consent paperwork in the API. The responsibility travels with the account that accepted the Terms, and abusing someone’s likeness is ground for losing that account.
What it runs on
- The API runs on managed cloud infrastructure, more than one instance behind a load balancer, so losing a single machine is not an outage.
- Generations run on GPU capacity held separately from the API, so a heavy render cannot slow down the endpoint that accepted it. That capacity is not tied to one provider, and we move it as availability, price and quality change.
- Generations are tracked in a shared ledger rather than in a process, which is why a poll can be answered by a different instance than the one that took the submission, and why a restart loses nothing.
- Finished assets are served from a CDN on signed URLs, not from the API.
- The feature you call is a recipe, not a model name. We change what runs underneath as better components appear, and your integration does not change with it.