Pentru dezvoltatori

Construiți cu Votinova

API REST, webhookuri, conectori și un server MCP. Tot ce face aplicația web se află și în API: creați o sesiune, o deschideți și aduceți rezultatele în sistemele Dumneavoastră în mai puțin de cinci minute.

  1. Creați o credențială în spațiul Dumneavoastră de lucru – două permisiuni, valabile în toată organizația.
  2. Faceți prima apelare: creați și deschideți o sesiune din curl.
  3. Abonați-vă la un webhook și primiți rezultatele pe măsură ce fiecare întrebare se închide.
curl -X POST https://api.votinova.prd.atbionapps.com/public/v1/sessions \  -H "X-API-Key: vz_live_…" \  -d '{ "presentation_id": "prs_8f3k2" }' 200 OK   · X-RateLimit-Remaining: 119{  "id": "ses_71xw9",  "join_code": "482913",  "state": "LIVE"}

Toate suprafețele, un singur contract

Fiecare integrare pornește din același document OpenAPI. Un punct final nou apare peste tot deodată.

Ce construiesc oamenii cu asta

Rezultatele în CRM-ul Dumneavoastră

Sincronizați răspunsurile și prezența în CRM-ul sau în depozitul Dumneavoastră de date, chiar în clipa în care fiecare întrebare se închide – vă anunță un webhook, fără interogări repetate.

Rapoartele Dumneavoastră

Indicatori, participanți și rezultate prin API, cu paginare cu cursor: construiți raportul exact cum îl vrea organizația Dumneavoastră.

Sesiuni din software-ul Dumneavoastră

Creați, deschideți și conduceți sesiuni din sistemul Dumneavoastră, din uneltele interne sau din agentul Dumneavoastră – același API pe care îl folosește și această aplicație web.

Făcut pentru agenți

Agentul Dumneavoastră știe deja Votinova

Un server MCP la distanță, cu instrumente derivate din documentul OpenAPI și filtrate după permisiunile credențialei Dumneavoastră. În plus, un llms.txt, ca orice model să găsească documentația.

Configurați serverul MCP
{  "mcpServers": {    "votinova": {      "url": "https://mcp.votinova.com/mcp",      "headers": { "Authorization": "Bearer vz_live_…" }    }  }}

Ultimele modificări ale API-ului

Istoricul modificărilor
  • ADDITIVE

    An event stranded by an auto-disable is now dead-lettered, so it can be replayed once the endpoint is back. Recovering from a bad afternoon is supposed to be: the platform pauses the endpoint, you fix it, you re-enable it, you redeliver what never arrived. Redelivery only accepts a dead-lettered delivery, and the queue of an auto-disabled endpoint was being terminated as merely failed — so there was nothing to replay and nothing said so. The arithmetic hid it: a delivery gets 8 attempts and an endpoint is paused after 10 consecutive failures, so a single event in flight always dead-letters first. The counter is per endpoint, and one ordinary session emits three events. Deliveries for an endpoint its owner REMOVED are still terminated without a dead letter: nobody is coming back for those.

  • ADDITIVE

    Three corrections found by driving this API the way an integration does. A bad request body now answers the envelope this surface documents ({ error, code: INVALID_REQUEST_BODY, invalid_fields }) naming the PUBLISHED field: it used to fall through to a shape the API emits nowhere else, which named the internal property (TargetUrl for target_url) and carried no error member for a generated client to read. session.ended is delivered ONCE per close; closing a live session through this API delivered it twice, so anything that posts a summary or books a room did it twice, and the event now always names presentation_id whichever surface closed the session. And enabling an endpoint only revives one the platform paused after failures: it used to undo a DELETE too, so a connector's unsubscribe could be reversed by one call while the connector itself could no longer remove it. Enabling an endpoint that was removed now answers 400 WEBHOOK_NOT_AUTO_DISABLED; register it again instead.

  • ADDITIVE

    question_id is now published as REQUIRED on per-question results, which is what the endpoint has always enforced: it answers 400 without one. The document said optional, so an integrator who believed it did not send the value and found out from a failed call — and the failed call counted against the organization's quota. Nothing about the endpoint's behaviour changed, and no request that worked before stops working; what changed is that the reference now describes it. Generated clients and MCP tools derived from this document will ask for the question up front instead of discovering the rule at runtime.

Cota pe fiecare plan

  • STARTERCereri: 120 la fiecare 60 s
  • PROCereri: 120 la fiecare 60 s
  • TEAMCereri: 600 la fiecare 60 s
  • ENTERPRISECereri: 3000 la fiecare 60 s

Cota Dumneavoastră călătorește în fiecare răspuns (anteturile X-RateLimit-*).