Support

The form below. It reaches a person rather than a queue, and it is the only channel we can promise to read, which is why it is the one shown here. There is no chat widget and no support inbox to guess at; anything that looks like one is not us.

It works whether or not you are signed in, because somebody locked out of their account is exactly the person who most needs to reach us. Signed in, it attaches your organisation so nobody has to describe which account they mean.

The Vatan contact form is for consultancy enquiries. Use this one for the Gateway: a broken product routed through a sales pipeline gets filed as an opportunity rather than fixed.

One thing matters more than everything else: the request id. Every response carries x-vatan-request-id, and with it we can see exactly which model answered, which route it took, what it cost, how long it took and how it failed. Without it, the first reply is a request for it.

x-vatan-request-id: 3f0c1e5a-2b77-4a91-9c0d-5f2a7e1b8d43

If a request never got that far, send the model id, roughly when it happened, and the error body verbatim. The error carries a code, and the code is what tells us which of a dozen different problems you have.

Never send an API key, in any channel. We cannot read one back to you anyway: keys are stored only as a hash. If you think one has leaked, revoke it on the keys page first and tell us afterwards.

Most of what people write in about is answerable from the dashboard in less time than the message takes to write:

• A request failed. The request log keeps the status and error code for every one, and every code is documented with what to do about it.
• Requests stopped working suddenly. Usually credit, a per-key budget or your plan's monthly allowance. All three answer 402 with a different code saying which.
• A webhook is not arriving. The delivery log on the webhooks page keeps every delivery with the number of attempts and the response code your endpoint gave us.
• The bill is higher than expected. The usage page groups spend by model, key, prompt, session and end user, so the answer is usually one dropdown away.

Support is free plan by email, priority email on Pro, and a named contact on Enterprise. We would rather say that plainly than publish a response time we cannot hold to: this is a small team, and an unmet promise about answering is worse than an honest one about not.

If something is broken on our side we would rather hear about it twice than not at all. A duplicate report costs us a minute; a silent outage costs you a day.

For anything security-related, or a question about where data goes, start with trust and security and mark the message as security when you write in.

Two facts that answer most of these before they are asked. The request log is metadata only, on every plan: prompts and completions are not stored in it. The one exception is the response cache, which you switch on per request with an x-vatan-cache header, and which keeps that answer for the lifetime you asked for. And some models are served through OpenRouter rather than an account we hold directly, which means your request body reaches that vendor by way of a third party; how a request is served says which and why.