Uttera · Documentation

How to ask for help

One address and that's it: support@uttera.ai. A person answers.

There's no form, no ticket number, and no bot asking whether you've tried restarting. When the volume calls for it we'll build something with more machinery, and it will be said here; until then, an email arrives sooner and gets answered just the same.

If what you want to know is whether the service is down rather than whether it's just you, that's checked before writing: service status.

What to send us

This is almost always enough to work out what happened without having to ask you for anything else:

Item	Where it comes from
`X-Request-Id` — the most important one	A header on the response that failed. It identifies your exact request among all of the day's.
Approximate time and time zone	Your clock. Without the zone, a time is no use at all.
The endpoint	`/v1/audio/transcriptions`, `/v1/summarize`…
What you expected and what happened	You. The literal error, if there is one, better pasted than summarized.
Your customer identifier	It's on your account page. It is not a credential: knowing it grants access to nothing.

Never send us your API key. Not the whole thing, and not "the first few characters just in case". We don't need it for anything: with the X-Request-Id we find the request. If we ever receive a key in an email, we will revoke it and tell you.

And if the problem is with a specific audio file, you don't need to send it to get started. Almost everything is diagnosed from the request identifier. If we ever needed the audio, we'll ask for it and explain what for — which is the only way a recording of yours can end up in our hands for longer than the seconds it takes to process it.

How long we take

This is what we commit to. It is time to first response on business days, not time to resolution: some faults are fixed in ten minutes and others aren't, but knowing that somebody is looking at it shouldn't depend on luck.

Plan	First response
Free	As we can. No commitment — but it does get read.
Startup · Developer	2 business days
Professional	1 business day
Business	4 business hours
Enterprise	Direct contact, agreed in the contract

This is not the SLA. Your plan's SLA is a commitment on service availability and stands on its own. An email answered late doesn't consume SLA, and a service that's down isn't fixed by answering an email quickly.

If something is genuinely broken

If you think you've found a bug of ours — not a usage question — say so in the subject. We deal with it before anything else, and if it turns out you were right we'll publish it: in this documentation if it changes something written here, and in the changelog if it touches the service.

And if what you've found is a security problem, write it to the same address with [seguridad] in the subject and don't publish it in the meantime. We'll reply with what we know and with a timeframe.