surveys
POST /v1/surveys/{survey_id}/responses
Record one person's answers to one survey.
認証
ベアラー トークンとして API キーを送信します。キーには org.read 権限が付与されている必要があります。権限のないキーは 404 ではなく 403 で拒否されます。
組織 ID を入力する場所
このエンドポイントは、JSONボディのフィールドとして org_id を受け取ります。
組織IDは、ダッシュボードのAPIキー画面にキーのすぐ横に表示されています。これは、実行するすべての呼び出しで同じIDになります。
試してみる
アングルブラケット内のすべてをご自身の値に置き換え、キーのプレースホルダーをご利用中のダッシュボードのキーに置き換えてください。
curl -X POST https://api.zinndigital.com/v1/surveys/{survey_id}/responses \
-H "Authorization: Bearer zdk_live_…" \
-H "Content-Type: application/json" \
-d '{ "answers": <SurveyAnswer[]> }'ログインしていますか？ダッシュボード内のAPIコンソールでは、実際の組織IDやお客様ご自身のキーが自動入力され、ライブAPIに対してリクエストが実行されるため、実際のレスポンスを確認することができます。 API コンソールでこのエンドポイントを開く
詳細
Stored in our own organisation-scoped table FIRST and unconditionally, then mirrored to the behavioural backend so the analytics join resolves. The two copies have opposite error policies deliberately: losing the customer's answer is unacceptable, losing the vendor's copy of an answer we already hold costs a join. ⛔ The survey is re-fetched and re-checked against the store — a client sends an id, and a client is a thing a person can edit. Answering an archived or stopped survey is refused. A SECOND answer from the same person returns `200` with `duplicate: true` rather than a conflict: the unique constraint exists to stop a doubled count, and the commonest way it fires is a retry after a dropped connection. Requires `org.read`.
パラメータ
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
survey_id (path) | string | はい | — |
リクエスト本文
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
org_id | string | いいえ | — |
distinct_id | string | いいえ | The browser's analytics distinct id. ⛔ Without it the mirrored event attaches to a person who does not exist, and the join looks healthy and is empty. |
path | string | いいえ | — |
answers | SurveyAnswer[] | はい | — |
返信
| 名前 | タイプ | 必須 | これがその内容です |
|---|---|---|---|
recorded | boolean | はい | — |
duplicate | boolean | はい | True when this person had already answered. ⛔ Reported as a success, not a conflict — the commonest cause is a retry after a dropped connection, and telling the customer it fail… |
id | string | いいえ | — |
このエンドポイントが返すエラー
401 · 403 · 404 · 422