• Series voir-pages
  • page 15 / 26
  • live connections 3
  • product ports implemented 0

An integration is not a partner logo on a website. It is a port with a handler that either answers the request or is honestly marked target architecture.

Integration pages usually look like a wall of logos: thirty familiar names and not a single answer to the question "what actually works?". We did the opposite. Here every connection carries a status, and the status is verified by querying a live endpoint — not by reading a roadmap. As of the publication date the picture is this: the VOIR AI product has zero implemented connections — the product is not launched. Three connections do run live in the Marisova ecosystem we build on: the Telegram Bot API, Telegram Stars and YooKassa. Six product ports — CRM, payment gateway, email and calendar, telephony, data warehouses, event bus — are designed and labelled target architecture. The live connections are not for sale and are not part of the product: they prove we know how to ship an integration to production, not that we already have one.

3 live connections · Marisova ecosystem 6 product ports · target architecture

See the bus map Honest statuses

Demonstration · bus map

One and the same path, two different worlds

An integration is proven not by a list of names but by a signal getting through: the request came in, reached a handler, the handler answered, the fact was recorded. We show one path — "the customer pays and gets access" — in two scenarios. The first describes a circuit that really works in the Marisova ecosystem: every step there is backed by live code. The second walks the same route through the VOIR AI product and runs into closed ports — because the product does not exist yet. Switch scenarios to see the difference. The demo plays pre-recorded scenarios and is not connected to live services; the facts are written out in the "Live connections" and "Target architecture" sections.

Structural numbers of this page: 3 live connections, 6 target-architecture ports, 2 demo scenarios, 0 implemented connections in the product.

Integration bus · signal from customer to access

Demonstration · pre-recorded scenario
  1. USER Customer and interface waiting
  2. CHANNEL Entry channel: bot, mini app waiting
  3. PAYMENTS Payment provider waiting
  4. WEBHOOK Fact confirmation waiting
  5. ACCESS Access and data record waiting
The log and port states are a pre-recorded scenario, not a live run.

Live connections works in the ecosystem

Three integrations that answer requests today

These are not integrations of the VOIR AI product — they are working connections of the Marisova ecosystem, which we build on and use every day. We list them for one reason only: they prove the architecture on this page is not invented but field-tested on ourselves. Every card carries a verifiable fact: a service state, an endpoint response, or a handler present in live code. None of these integrations are handed to or sold to customers.

TG-BOT

Telegram Bot API

live connection

The @marisova_rubot bot is the ecosystem's entry point: user authorization, mini-app launch, sale notifications to the owner, content delivery. Update handling, inline keyboards, WebApp links and startapp deep-link parameters all run in production. For VOIR AI this is the prototype of the entry channel: in the target architecture the customer talks to the system through the messenger they already use, not through yet another portal they have to remember.

Fact: the bot system service is active and running on the ecosystem server; the bot code contains update and invoice handlers.

TG-STARS

Telegram Stars (XTR)

live connection

Telegram's built-in currency: invoices are created with an empty provider_token and the XTR currency, including native auto-renewing subscriptions. The whole cycle stays inside the messenger — no redirect to an external site, no card entry, no separate payment form. The pre_checkout_query and successful_payment handlers confirm the fact of payment and grant access. For the product this is the model of a short payment circuit: the fewest possible steps between intent and result.

Fact: XTR invoices are present in the live bot code along with both payment handlers; ecosystem plans are priced in Stars.

YOOKASSA

YooKassa API v3

live connection

The payment rail for card payments in rubles — where Stars does not fit. Implemented as a standalone standard-library module: payment creation with an idempotence key, redirect confirmation, status checks through the API as the source of truth, refunds. The provider's webhooks carry no signature, so authenticity is verified two ways: YooKassa's IP allowlist and a repeated status query for the payment. This is the principle we carry into the product: never take a notification at its word — re-check the fact.

Fact: the public SKU storefront answers HTTP 200, while the payment creation and status routes answer 401 — the handlers exist and are closed behind authorization.

Alongside these three connections the ecosystem also runs internal services that are better described as infrastructure than as integrations: PDF generation via a headless browser, speech recognition, search over a book corpus, and a call-center API with a call queue and transcripts. The last one deserves an honest clarification: the API exists and answers, but live calls through a telephony provider are not connected. That is why telephony stays in the target-architecture zone of the status table rather than among the live connections.

Target architecture not implemented

Six ports that are designed but not connected

A port is not "we plan to support X". A port describes what data comes in, what goes out, who owns the connection and what happens on failure. Below are the six ports of the VOIR AI product as designed. Not a single line of code has been written for any of them, and we show no connect buttons: a UI control that looks working and does not work is deception, however pretty.

CRM: 1C, Bitrix24, amoCRM

Target architecture

The deals-and-contacts port. In the target architecture AI Sales reads the pipeline, enriches a deal with data from correspondence and returns the next step — and the department does not know which particular CRM is connected: it works with a normalized deal model through an adapter. Synchronization is two-way; conflicts resolve in favour of the more recently modified record, with both versions kept in the journal.

Why not implemented: there is no product and no customers whose CRMs could be connected.

Product payment gateway

Target architecture

The port for paying for VOIR AI plans. A separate entity, not a copy of the ecosystem rail: the product has its own plans, documents and accounting. The circuit requirements are already formulated and field-tested on YooKassa: idempotent payment creation, status from the API as the source of truth, notification re-verification, refunds with a journal. There is no implementation — the plans on the pricing page are a launch plan, not an active offer.

Why not implemented: the product is not launched; there is nothing to sell.

Email and calendar

Target architecture

The correspondence-and-schedule port. AI Operations receives incoming emails from it as process events, and the AI CEO reads the owner's availability for planning. The principle is the same: the system reads and proposes, but never sends an email or moves a meeting without explicit human confirmation. Autonomous outward action — only with permission written into the regulation.

Why not implemented: the port is designed; no code has been written.

Telephony

Target architecture

The calls port: incoming calls as events, outgoing calls per a confirmed script, transcript and conversation summary as an artifact. The Marisova ecosystem does have a call-center API — queue, campaigns, transcripts — but live calls through a telephony provider are not connected, so we do not list this item among the live connections. The honest wording: the interface exists, the channel does not.

Why not implemented: no telephony provider connection exists in either the ecosystem or the product.

Data warehouses and BI

Target architecture

The read-only port to marts and reports. AI Finance and AI Research read metrics from it with no right to write into someone else's warehouse. The restriction is deliberate: a system that can alter source data stops being a trusted reporter. Access — via separate credentials with the least sufficient scope.

Why not implemented: the port is designed; no code has been written.

Event bus and webhooks

Target architecture

The port through which external systems tell the product about facts: a payment went through, a lead was created, a document was signed. The bus is the foundation of the AI CEO cycle: an event becomes a task trigger, not a reason for manual monitoring. The requirements are already field-tested on YooKassa webhooks: a notification is not proof; the fact is re-verified by querying the source. There is no implementation in the product.

Why not implemented: the product bus is not written; only the payment provider's webhooks work in the ecosystem.

Connection principles

Four rules that do not depend on the service name

Integrations come and go: providers change their APIs, services shut down, regulatory requirements get updated. The rules below describe not particular connections but how we connect anything at all. They are drawn from the Marisova ecosystem practice and applied to the product ports in the target architecture.

A notification is not proof

A webhook can arrive forged, duplicated or stale. The fact of an operation is confirmed by querying the source of truth — the payment or record status is read through the provider's API, not taken from the notification body. Additionally, the connection is restricted to the provider's address list. This is exactly how the live YooKassa circuit in the ecosystem works.

Idempotence is mandatory

Networks break, requests repeat, and a provider can return 500 without the operation having failed. Every creating action carries a unique key so a retry cannot spawn a second payment or a second record. "Check the status first, decide second" is the mandatory order for handling a failure.

Least sufficient scope

A connection receives exactly the rights its port needs: read deals without the right to delete them, access report marts without write access, send a notification without access to correspondence. Keys are kept outside the code and never reach a log, a report, or this page.

A failed port must not sink the system

An external service being unavailable is a routine condition, not an accident. A port must have a timeout, a bounded retry, and an explicit "data not received" state that the department reports upward honestly. Silently substituting stubs for real data is forbidden: it turns an outage into a plausible-looking lie.

Statuses

Two status columns: the product and our own workshop

The table is split deliberately. The left column — what is implemented in the VOIR AI product (currently not a single connection). The right column — what already works inside our Marisova ecosystem and by which fact it is confirmed. The right column must not be read as a promise to a customer: our internal integrations are not sold or handed over — they only prove that the port requirements are not invented but field-tested on a live circuit.

Integration statuses as of November 3, 2026. Verified by querying live endpoints and service states — not by reading plans.
Integration In the VOIR AI product In the Marisova ecosystem (internal)
Telegram Bot API not implemented
Target architecture: the customer entry channel and report delivery		 live connection
The @marisova_rubot bot: authorization, mini app, notifications, content delivery. The system service is active and running
Telegram Stars (XTR) not implemented
Target architecture: a short payment circuit inside the messenger		 live connection
XTR invoices with auto-renewal; pre_checkout_query and successful_payment handlers in the live bot code
YooKassa API v3 not implemented
Target architecture: paying for product plans by card		 live connection
The SKU storefront answers 200; payment creation and status routes answer 401 — the handlers exist and are closed behind authorization
CRM: 1C, Bitrix24, amoCRM not implemented
Target architecture: a normalized deal model through an adapter		 does not exist
No connectors in either the ecosystem or the product
Product payment gateway not implemented
Target architecture: VOIR AI's own plans, documents and accounting		 different product
The ecosystem payment circuit serves marisova.ru and is not part of VOIR AI
Email and calendar not implemented
Target architecture: emails as process events, availability for planning		 does not exist
No connections to email providers or calendars
Telephony not implemented
Target architecture: calls as events, transcript and summary as an artifact		 partial
The call-center API exists and answers (queue, campaigns, transcripts), but live calls through a telephony provider are not connected
Data warehouses and BI not implemented
Target architecture: read-only access to marts and reports		 does not exist
No connections to external warehouses; the ecosystem's internal databases are not an integration
Product event bus and webhooks not implemented
Target architecture: an event becomes a task trigger of the AI CEO cycle		 partial
The payment provider's webhooks work, with an IP allowlist and status re-verification; the ecosystem has no general event bus
Interactive bus demo on this page Demonstration
Pre-recorded scenarios in a browser script		 not a live service
Makes no external network calls, sends no payments, executes nothing and collects nothing
Integration as a customer service not implemented
Target architecture: the customer connects their own systems to VOIR AI		 does not exist
No customers, the product is not launched; the ecosystem's internal integrations are not handed over

Connection security

An integration widens the attack surface — and that must be admitted

Every connected service is one more door into the system. That is why security requirements for ports matter no less than data requirements. Below are the rules already applied in the ecosystem's live circuit and baked into the product's target architecture.

Keys stay out of the code

Integration credentials live in the service environment and never reach source files, logs, or reports. This page contains no keys — not even masked ones: publishing a secret is a leak in itself.

Verifiable source

Where a provider does not sign notifications, authenticity is confirmed otherwise: by restricting to the provider's address list and re-querying the status through the API. A notification is treated as a signal to check, not as a finished fact.

Separated access

Payment routes that touch user data are closed behind authorization: without proven identity a request gets a refusal, not data. Only what is meant for everyone stays public — for example, the price-list storefront.

Outward action needs confirmation

The system does not send an email, make a payment or move a meeting on its own unless a regulation says so explicitly. Autonomy ends where an irreversible outward action begins: that requires human confirmation.

Boundaries

What this page does NOT claim

Honesty is the project owner's requirement, not a marketing move. We fix the boundaries explicitly so they cannot be read two ways.

  • The VOIR AI product has zero integrations. None of the six target-architecture ports is implemented in product code. The live connections belong to the Marisova ecosystem and are not part of the product.
  • No customers, no deployments. The page has no partner logos, no connection case studies, no testimonials and no deployment metrics — because there is not a single deployment. We do not paint logo walls.
  • The demo is pre-recorded. Both signal-along-the-bus scenarios are played by a browser script and make no calls to live services: not to payment providers, not to Telegram, not to the outside network at all.
  • No dead controls. We publish no "Connect CRM" or "Link email" buttons and no integration-picker form: whatever looks working must work. The page's only interactivity is the demo scenario switches, anchors and links to real pages.
  • Telephony is not claimed as live. The ecosystem's call-center API exists, but there is no call channel through a telephony provider. That is why telephony sits in target architecture, not among the live connections.
  • Secrets are never published. No shop identifiers, no API keys, no internal service addresses appear on this page. The statuses were verified by querying endpoints; the credentials themselves stayed in the server environment.

Questions and answers

Frequently asked questions about integrations

Which VOIR AI integrations work right now?

Inside the VOIR AI product — none: the product is not launched and has no customers. Three connections genuinely run live in the Marisova ecosystem we build on: the Telegram Bot API (the @marisova_rubot bot as a system service), Telegram Stars (XTR invoices with auto-renewal) and YooKassa API v3 (SKU storefront and payment routes). These are our own working integrations; they are not for sale and are not part of the VOIR AI product. All six product ports — CRM, payment gateway, email and calendar, telephony, data warehouses, event bus — belong to the target architecture.

How did you verify that a connection is live?

By querying live endpoints, not by reading roadmaps. For YooKassa: the public SKU storefront answers HTTP 200, while the payment-creation and payment-status routes answer 401 — meaning the handlers exist and are protected by authorization. For Telegram: the bot system service is active and running, and the live bot code contains XTR-currency invoices plus pre_checkout_query and successful_payment handlers. That is why the status table on this page is split into two columns: "in the product" and "in the ecosystem".

Can we connect VOIR AI to our CRM today?

No. A connector to 1C, Bitrix24 or amoCRM does not exist in any form: what exists is a port description in the target architecture and a clear understanding of which data should flow through it. We deliberately do not publish a "Connect CRM" button that would lead nowhere — a dead control that looks real is, to us, a form of deception.

Why don't the live payments count as a product integration?

Because they serve a different product. Telegram Stars and YooKassa take payment for subscriptions and services of marisova.ru — that is the Marisova ecosystem. The VOIR AI product is not launched; it has neither plans on sale nor a payment circuit. Porting a working payment rail over is technically feasible, but as of the day this page was published it is not part of VOIR AI, and we do not present it as a ready capability.

How do integrations relate to the AI departments?

Integrations are the perimeter through which departments receive data and return results. AI Sales works with deals from the CRM, AI Finance with payment-gateway transactions, AI Operations with bus events, AI Marketing with email and messenger channels. In the target architecture a department does not know which particular CRM is connected: it works with normalized data through a port. Department design is covered on the respective pages, and how departments assemble into one system — on the AI Operating System page.

Does the demo on this page connect to live services?

No. It is a demonstration: a browser script plays two pre-recorded scenarios — "live circuit" (how the payment path really works in the Marisova ecosystem) and "target architecture" (the same path inside the VOIR AI product, where every port is closed). The script sends no requests to payment providers, to Telegram, or to the outside network at all; it executes nothing and collects nothing.

Need an integration that is not listed here?

The VOIR AI product is in development, has no customers, and we do not collect "waiting list" signups through this page. Write to us directly: tell us which systems you already run and which data path needs automating — and we will honestly say what is designed, what we have already field-tested in our ecosystem, and what does not exist in any form. The overall system architecture is on the AI Operating System page, the department lineup — on the home page, and the delivery pipeline — on the AI Development page.

Write to us Launch plans and pricing