開発者の方へ

Votinova で開発する

REST API、webhook、コネクター、MCP サーバーをご用意しています。ウェブアプリでできることはすべて API にもあります。セッションを作って開き、結果を自社の仕組みに取り込むまで5分もかかりません。

  1. ワークスペースで認証情報を作成します。スコープは2つ、組織全体に適用されます。
  2. 最初の呼び出しを実行します。curl でセッションを作成して開きます。
  3. webhook を登録し、質問が締め切られるたびに結果を受け取ります。
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"}

どの入り口も、契約はひとつ

すべての連携は同じ OpenAPI ドキュメントから作られています。新しいエンドポイントはすべての入り口に同時に現れます。

こんな使い方があります

結果を CRM へ

質問が締め切られた瞬間に、回答と出席を CRM やデータウェアハウスへ同期します。webhook が知らせてくれるのでポーリングは不要です。

自社のレポート

主要指標、参加者、結果をカーソルページング付きの API で取得できます。組織のやり方どおりのレポートを作れます。

自社ソフトからセッションを

バックエンドからでも社内ツールからでもエージェントからでも、セッションの作成、開始、進行ができます。このウェブアプリが使っているのと同じ API です。

エージェントのために

あなたのエージェントはもう Votinova を知っています

OpenAPI ドキュメントから作られ、認証情報のスコープで絞り込まれたツールを備えたリモート MCP サーバーです。llms.txt も用意しているので、どのモデルからでもドキュメントを見つけられます。

MCP サーバーを設定
{  "mcpServers": {    "votinova": {      "url": "https://mcp.votinova.com/mcp",      "headers": { "Authorization": "Bearer vz_live_…" }    }  }}

API の最新の変更

変更履歴
  • 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.

プランごとの上限

  • STARTER60秒あたり120リクエスト
  • PRO60秒あたり120リクエスト
  • TEAM60秒あたり600リクエスト
  • ENTERPRISE60秒あたり3000リクエスト

残りの上限はすべてのレスポンスに含まれます(X-RateLimit-* ヘッダー)。