VOIR AI has no public API — the product has not launched, and
nothing answers at api.voir.su. What we do have is a designed API
surface: resources, methods, error format, auth model and rate limits. We publish
it as target architecture so a future
partner can see the interface they would get and sanity-check our promises. There
will be no interactive “sandbox” pretending to be live: a fake 200 OK
in a console misleads far worse than an honest “0 of 12 implemented”.
12 endpoints · target architecture no sandbox · by design
As of the day this page was published, here is where things stand:
api.voir.su serves nothing, and no keys are issued.voir_sk_…) are not valid and the identifiers are fictional.So why publish this page? Because the API surface is designed: we know which resources will appear, which methods they need and what errors will look like. Showing the contract early respects the time of anyone planning an integration. It is the same honesty logic as our pricing: we do not sell what we do not have.
Structural numbers of this page: 12 planned endpoints, 3 resource groups, 3 roadmap phases, 0 implemented endpoints.
Planned endpoints Target architecture
The surface mirrors what the product does in the UI: accept a task, decompose it into subtasks, assign departments, return the result. Hence the same resources — tasks, agent and team runs, webhooks for events, and an account profile utility. Below is the full plan for the first public release: path, method, purpose and what the endpoint will return. None of them can be called.
The programmatic twin of delegating through the AI CEO: task text, priority, deadline and optional department constraints. The system takes the task into decomposition and returns its identifier.
Paginated account tasks with filters by state (accepted, decomposed, running, completed) and by executing department. Cursor pagination, as in the examples below.
The full state of one task: subtasks after the AI CEO decomposition, assigned departments, current execution statuses and the merged result once it is ready.
Refine priority, deadline or wording while the task is still in decomposition. Changing a task already assigned to departments creates a new decomposition revision — the old one stays in history.
The AI agents available to the account under its plan: role, department, skills and current load. The same catalogue the platform UI shows.
A pinpoint run of a single agent with an instruction and input data, bypassing full task decomposition. For integrations that need one specific executor — say, lead qualification by the sales agent.
The state of one run: queued, running, completed with a result, or failed with a machine-readable code. Long runs are polled through this endpoint or delivered by webhook.
Hand a task to a team — a group of agents with internal routing. The team distributes subtasks among its members; to the caller it is one resource, not manual orchestration.
Register a URL and an event set (task decomposed, run completed, result merged). Every notification is signed with the subscription's HMAC key: the receiver verifies the signature and does not take it on faith — the same principle as the live YooKassa circuit.
All active account subscriptions with their events and delivery state. Undelivered events are stored and retried with exponential backoff — retries are visible in the list.
Unsubscribe: events stop going to the URL, delivery history stays in the account for review. The operation is idempotent — a repeated DELETE returns the same success.
Who owns the key: account, plan, available departments and current limit consumption — requests per window, active runs, queue depth. A utility endpoint for integration self-diagnosis.
Anatomy Demonstration · static text
Both blocks below are static text, not a live console: the browser sends nothing anywhere, and the identifiers and keys are fictional. We show the shape of the contract — request structure, success format and error format — so an integration can be designed today, without waiting for launch.
POST /v1/tasks HTTP/1.1
Host: api.voir.su
Authorization: Bearer voir_sk_test_0000000000
Content-Type: application/json
Idempotency-Key: 7c1e0a42-b8f3
{
"title": "Investigate the October cash gap",
"priority": "high",
"deadline": "2026-11-10T18:00:00Z",
"departments": ["finance", "sales"],
"context": "Revenue is there, the account is negative — need a breakdown."
}HTTP/1.1 201 Created
Content-Type: application/json
{
"object": "task",
"id": "task_9f2c41de",
"state": "accepted",
"title": "Investigate the October cash gap",
"priority": "high",
"departments": ["finance", "sales"],
"created_at": "2026-11-03T09:00:00Z",
"decomposition": null
}HTTP/1.1 422 Unprocessable Entity
{
"error": {
"type": "validation_error",
"code": "department_not_available",
"message": "Department 'legal' is not included in the account plan.",
"param": "departments[0]",
"request_id": "req_51ab77c0"
}
}
Every error carries a machine-readable code, a human-readable
message, a pointer to the exact parameter and a request_id
for support. Errors are designed so an integration can tell “fix your request”
(4xx) from “retry later” (429, 5xx) without reading between the lines of the docs.
Principles Target architecture
Concrete field formats may be refined — that is what versioning is for. But the foundational principles of the surface are settled and will not be revisited: they come from the live integrations of the Marisova ecosystem and from common sense. If you are designing an integration, these six points are safe to build on today.
voir_sk_… (secret) and voir_pk_… (public, read-only
catalogue access). A token belongs to an account, not a person; zero-downtime
rotation means issuing a new key while the old one lives through a grace period.
Keys are never logged and never returned in responses.
Idempotency-Key header is required on POST requests: a retry with the
same key returns the first result instead of creating a second object. Networks are
unreliable — retries must not produce duplicate tasks or runs.
error.type / code / message / param / request_id structure is uniform
across all endpoints. code values are part of the contract: they do not
change within a version, so your handler will not break after our release.
X-RateLimit-Limit,
X-RateLimit-Remaining and X-RateLimit-Reset; on exceeding —
an honest 429 with Retry-After, not silent throttling. An
integration always knows how much budget it has left.
Roadmap Target architecture
We do not name deadlines, because a missed announced date is the same fake sandbox, only in a calendar. The phase order is the commitment we are ready to make: a working core first, then events, then the public surface. Each phase becomes visible on this page when it actually starts.
The internal product circuit: task intake, AI CEO decomposition, department assignment, agent runs, result merging. First for the platform's own UI — the API layer grows out of an already working core instead of being designed in a vacuum.
status: not startedThe product event bus: subscriptions, HMAC signatures, retry of undelivered notifications, delivery log. Without reliable events an API degrades into polling for polling's sake — so this phase precedes the public release.
status: not startedAPI key issuance, plan-based rate limits, documentation with examples from live responses — and only then a sandbox that is genuinely live, because a real server stands behind it. Until that moment this page stays an honest plan.
status: not startedFAQ
No. There is no public API: the VOIR AI product has not launched, and there is no server issuing keys. Everything on this page is target architecture — a design of how the API will work. If anyone offers you a “VOIR AI API key”, it is not us.
So partners and future customers can evaluate the integration contract in advance and judge whether it fits their stack. That is more honest than a “coming soon” stub: we show the real interface design — resources, methods, error format, auth model — and clearly label it as not yet implemented.
No, and deliberately so. A sandbox that looks live but answers with recorded scenarios would mislead — exactly what this page argues against. All request and response examples here are static and labelled “example — target architecture”.
No dates. The order of work is in the roadmap section: task and agent core first, then the event bus and webhooks, then public key issuance with plan-based limits. An announced date that slips deceives just like a fake 200 OK in a console.
In the Marisova ecosystem we build on, Telegram Bot API, Telegram Stars and YooKassa API v3 are live. These are internal connections: verified with requests to live endpoints, not for sale, and not part of the VOIR AI product. The full breakdown with facts is on the integrations page.
We do not sell what we do not have — but we do not hide our plans either. If your integration depends on this contract, write to us: we can discuss pilot participation, the phase order and which resources you specifically need. Meanwhile, see what already works in the ecosystem and how the platform is designed.