For utviklere
Bygg med Votinova
REST-API, webhooks, koblinger og en MCP-server. Alt nettappen gjør, ligger også i API-et: opprett en økt, åpne den og få resultatene inn i dine egne systemer på under fem minutter.
- Lag en tilgangsnøkkel i arbeidsområdet ditt – to tillatelser, for hele organisasjonen.
- Gjør ditt første kall: opprett og åpne en økt fra curl.
- Abonner på en webhook og få resultatene etter hvert som spørsmålene lukkes.
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"}Alle flatene, én kontrakt
Alle integrasjonene er utledet fra det samme OpenAPI-dokumentet. Et nytt endepunkt dukker opp alle steder samtidig.
REST-API
Offentlige endepunkter med tillatelser, kvoter per abonnement og markørbasert paginering.
API-referanse →Webhooks
HMAC-signerte hendelser med økende ventetid mellom forsøkene og manuell ny sending.
Veiledning for webhooks →Zapier
Utløsere og handlinger som automatiserer uten kode.
Se integrasjonen →Power Automate
Kobling med webhook-utløser for Microsoft-økosystemet.
Se integrasjonen →MCP-server
Verktøy til agentene dine, utledet fra OpenAPI-dokumentet. Ekstern, ingenting å installere.
Sett opp MCP →Tillegg
PowerPoint, Google Slides, Teams, Zoom og Webex.
Se tilleggene →Dette bygger folk med det
Resultater i CRM-et ditt
Synkroniser svar og oppmøte inn i CRM-et eller datavarehuset ditt i det øyeblikket hvert spørsmål lukkes – en webhook sier fra, ingen gjentatte spørringer.
Din egen rapportering
Nøkkeltall, deltakere og resultater via API-et med markørbasert paginering: bygg rapporten nøyaktig slik organisasjonen din vil ha den.
Økter fra din egen programvare
Opprett, åpne og styr økter fra backend-en din, de interne verktøyene dine eller agenten din – det samme API-et som denne nettappen bruker.
Ditt første kall, i språket du koder i
Hele veiledningen →Laget for agenter
Agenten din kan allerede Votinova
En ekstern MCP-server med verktøy utledet fra OpenAPI-dokumentet, filtrert etter tillatelsene til tilgangsnøkkelen din. I tillegg en llms.txt, slik at enhver modell finner dokumentasjonen.
Sett opp MCP-serveren →{ "mcpServers": { "votinova": { "url": "https://mcp.votinova.com/mcp", "headers": { "Authorization": "Bearer vz_live_…" } } }}Siste endringer i API-et
Endringslogg →- 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.
Kvote per abonnement
- STARTER120 forespørsler per 60 s
- PRO120 forespørsler per 60 s
- TEAM600 forespørsler per 60 s
- ENTERPRISE3 000 forespørsler per 60 s
Kvoten din følger med i hvert svar (X-RateLimit-*-headere).