Support
Where to write, what to attach to a message, where to see the state of the services, and where the legal documents live.
Where to write
The support addresses are not written into this text, and that is not forgetfulness: the channels are published by the platform itself, and a page that repeated an address would diverge from it on the first day.
The channels in force are collected on one page: the contacts page of the main site. The news channel and the way to a manager are there too.
From the console there is a second route: the product panel carries a separate entrance for a bug report, which is convenient for sending what you are looking at right now without retelling it.
What to attach
A message that carries these is usually closed by one answer.
- The call IDThe `X-Request-Id` header from the answer, or the same string on the call's card in the log. It is a real lookup key for an entry in the platform log.
- The timeThe instant of the call, with its time zone.
- The modelAs you named it in the request.
- The key's nameThe one you gave it, and if you like the fragments it is shown by in the list.
- The answer you gotThe status, and the `type` and `code` from the refusal envelope.
Do not send a key's secret — not in an email, not in a screenshot, not "partly". Support does not need it: a key is found by its name and its display fragments. A secret that reaches a conversation has to be treated as compromised and replaced.
For the same reason there is no point asking for the content of a request to be recovered: prompts and answers are not stored, and only you can attach them to an investigation.
Where to find the identifier → What a status means →
The state of the services
If you suspect an outage, look at the status board on the main site first — the same board is repeated in the console.
It carries eight components in two groups: Kumo itself — the gateway, routing, the console, billing and metering — and the model providers behind them. Each carries one state: operational, partial failure, unavailable, or not observed. The last means exactly what it says: the platform does not establish that component's state and does not invent one for it.
Under every component is a ninety-day window, in which a day with nothing recorded for it is drawn as exactly that. Observation runs once a minute, and what is counted is days rather than percentages: there is nothing rounded there, and nobody will do the division for you.
Incidents are recorded as a list of their own: a span opens when measurements confirm a component has stopped serving requests, and closes when it serves them again.
Raising limits
Raising a ceiling is a conversation, not a setting. Ceilings are editable neither in the console nor by a request member. Write to support describing the traffic you need to push through — its shape, not only its peak.
The same holds for two other cases: changing a username again once both changes are spent, and deleting an account, a request that is handled by hand.
What a key is issued with → The account and its deletion →
Legal documents
The documents section lives on the main site. Three documents are there in full:
- the Public Offer — the terms you accepted at registration;
- the Privacy Policy;
- the partner program terms.
Beside them are two short notes with no document of their own: on how long purchased tokens stay valid, and on the data-processing addendum, which is offered on request.