For business

Mixen API was built for one job: giving a Russian team access to models from OpenAI, Anthropic, Google, xAI and the rest without a foreign card, a middleman or a VPN. Below is what matters to a product rather than to a lone developer.

Payment

The balance is topped up in roubles: cards and SBP through acquiring, plus cryptocurrency. Charges come off the balance for actual usage — there is no subscription and no minimum spend, and an unused remainder can be refunded under the refund terms.

Catalog prices are given in both roubles and dollars: GET /v1/models returns a pricing block per model — those are exactly the figures you are billed by.

Keys and access

• Create as many keys as you need — one per service, per environment, per contractor. A key is shown once and stored as a hash; a lost key is not recovered, it is reissued.
• A key can be restricted with scopes — a set of capabilities (chat, images, audio, video, music, embeddings, search). A call outside the scope gets 403, so an image key cannot burn the budget on video.
• The default limit is 60 requests per minute per key, with 429 and Retry-After on excess. Need more — write to support; the limit is set per key.
• Revoking a key takes effect immediately.

Spend tracking

What you need	Where to get it
Current balance	GET /v1/balance
Per-request charge log	GET /v1/history
Generation history with artifacts	GET /v1/generations
Model prices and capabilities	GET /v1/models

Spend is recorded per request, so the unit cost of a feature in your product comes out of the log rather than out of a monthly total. On long repeated prompts, context caching cuts the price noticeably — it engages by itself and is billed below the normal input rate.

Data

Only the content of a request reaches the upstream — no user identifier, contacts or payment history. The details and the legal wording are in the privacy policy and in the Privacy section.

Worth knowing up front

• The contract is a public offer addressed to a natural person (text, in Russian). If you need it with a legal entity, write to support before you start integrating: that is settled in conversation, not automatically.
• We do not sign an uptime SLA. The service runs on blue/green deploys with monitoring, but the offer carries no formal availability guarantee — build retries and a fallback model into your integration.
• Models come and go. Providers retire versions and we follow them. Do not hardcode a model list — read it from GET /v1/models.

Next

• Quickstart — a key and the first request.
• Errors, limits, billing — response codes and what happens when funds run out.
• Partner programme — if you bring customers rather than integrate the API.