Katara support
Overview
OpenAI-compatible inference, paid per reply with account credits or USDC.
Katara API 1
Section titled “Katara API 1”Katara Cortex serves every request, from independent GPU providers in Katara Community and from Katara’s own models, whether it is paid with account credits or USDC. The API follows the OpenAI chat completions shape and also speaks the Messages and Responses formats, so existing clients work by changing the base URL and the key.
Authentication is a bearer key created in the portal. The key’s environment decides where a request is served and paid: a Live key on the Live network, in USDC or from Account Credits, and a Test key on the Test network, in test USDC or test credits. Networks names the chain and contracts of each. The settled price comes back on the response.
Format validation errors use the endpoint’s documented envelope. Payment challenges and
admission refusals retain their status, body and payment headers. The code field is stable;
the message is for people. Every response carries an x-katara-request-id header, repeated
as x-request-id and request-id for the OpenAI and Anthropic SDKs. Quote it when you contact
support. A path the API does not serve answers a JSON 404 not_found.
Authentication
Section titled “Authentication”messagesKey
Section titled “messagesKey”A Katara key. If Authorization is also sent, it must contain the same bearer key.
Security scheme type: apiKey
Header parameter name: x-api-key
bearerAuth
Section titled “bearerAuth”Authorization: Bearer kat_live_… or Bearer kat_test_…. A key made in a Live environment
starts kat_live_, one made in a Test environment kat_test_; the environment, not the prefix,
decides the network, so a key issued before prefixes followed the environment keeps working where it did.
Create keys in the portal under API Keys with an organization, an environment, the cortex:inference scope and an expiry. A key is shown once. Subsequent requests require current, unrevoked authority.
Security scheme type: http