Skip to main content

Public survey response (recipient-facing)

These two endpoints power the page a recipient lands on when they open a survey link. They are unauthenticated — the request carries no API key. Access is granted by the single-use token embedded in the link, so you never expose your API key to end users. The token is minted when you send a survey with POST /api/v1/surveys/{id}/send and is baked into the SMS, email, WhatsApp, RCS, or Viber message each recipient receives. Tokens are valid for 30 days. Most teams let recipients use the hosted page below; the JSON form of the submit endpoint is there for when you render your own response UI.
Do not send an X-API-Key header to these endpoints, and do not build the token yourself — always use the link returned by the send endpoint. Both endpoints are rate-limited to 10 requests per minute per IP.

Open the survey response page

GET /api/v1/public/surveys/{token}
string
required
The signed token from the survey link. An invalid or expired token returns a 404 page rather than revealing whether a survey exists.
Returns a self-contained HTML page with a 0–10 rating scale and, when the survey defines a follow-up prompt, a comment box. If the recipient has already answered, the page shows their recorded score instead of the form. The response is served with Cache-Control: private, no-store, so shared links are never cached.

Submit a survey response

POST /api/v1/public/surveys/{token}/submit
string
required
The signed token from the survey link.
integer
The rating, 010. Optional when a comment is provided.
string
A free-text comment, up to 2000 characters. Optional when a score is provided.
Send at least one of score or comment; a request with neither is rejected. The endpoint accepts either a JSON body or a standard application/x-www-form-urlencoded form post, so the hosted page and your own integration share the same route. Submitting again with the same token is safe — the first answer is kept and never double-counted. Set Accept: application/json to receive a JSON envelope; otherwise the endpoint returns an HTML thank-you page for browser form posts.
Errors

Reminder waves for non-responders

A survey’s response rate is set by what happens after the first send. Two endpoints close that loop: one lists the contacts who have not answered yet, and one re-sends the survey to them. This is safer than manually re-sending to a stale audience. A contact counts as a non-responder only while their latest send is unanswered — the moment they reply (from any earlier link), they drop out of the list and out of every future wave. Each reminder then runs through the same delivery guardrails as the original send — if a contact was already re-sent the survey (by a concurrent wave, an automation, or a manual resend) inside the 24-hour dedupe window, they come back skipped, never double-sent.

List non-responders

GET /api/v1/surveys/{id}/non-responders
string
required
The survey template id.
integer
How old a contact’s most recent send must be before they surface — defaults to 24. Ranges 18760. Bad values fall back to the default rather than erroring, so the list stays loadable.
integer
Page size, 1200, default 50.
integer
Pagination offset, default 0.
Returns the current non-responders for the survey — each with its contact id, the channel of the contact’s latest send, and that send’s timestamp — plus a total for the full list, so you can show “203 contacts still out” while rendering the first page.

Send a reminder wave

POST /api/v1/surveys/{id}/remind
string
required
The survey template id.
integer
Only contacts whose latest send is at least this old join the wave — default 24, range 18760.
array of strings
Restrict the wave to this subset of non-responders (max 1,000). Omit to wave at everyone GET /non-responders would currently list.
integer
Override the cross-survey fatigue cap for this wave (default 72 hours at platform level). Pass 0 to disable cross-survey fatigue capping for this wave.
Responds with requested, sent, and skipped counts — plus a skipped_by_reason breakdown (for example, deduped when the 24-hour same-survey recency check still guards the contact). When nobody is eligible yet, the response is { "requested": 0, "sent": 0, "skipped": 0, "reason": "no_non_responders" }. Every reminder re-uses the channel the contact’s last send used, so a WhatsApp non-responder is chased on WhatsApp, an email non-responder on email. The wave is also auditable — each POST /remind call is written to the audit log with the requested / sent / skipped totals.

Post-conversation scorecards by queue or agent

Post-conversation surveys (the auto-CSAT/NPS close-triggered dispatch and the post-call IVR captures) collect scores per interaction. GET /api/v1/surveys/scorecards rolls the answered responses up into one scorecard per queue (?group_by=queue, the default) or per handling agent (?group_by=agent), so a supervisor can compare teams and agents on the same headline metrics.
GET /api/v1/surveys/scorecards
string
queue (default) buckets by the queue that handled the interaction; agent buckets by the handling agent.
string
csat, nps, or all (default). Restrict the rollup to one metric.
string
Narrow to one queue bucket (with group_by=queue).
string
Narrow to one agent bucket (with group_by=agent).
string
ISO timestamp window lower bound. Only answered responses count.
string
ISO timestamp window upper bound.
integer
Page size, 1200 (default 50). A bucket with zero answers drops out entirely.
integer
Pagination offset, default 0.
Each row carries responses, satisfied_count, satisfaction_pct (share at score 4–5, the top-two-box), avg_score, csat_avg_score, and nps (promoters minus detractors, over NPS rows only) plus nps_responses. CSAT and NPS averages are kept independent — a blended mean across the two scales is meaningless.
Unanswered sends never distort the numbers: a queue or agent bucket appears only once it has at least one answered response, so sampled-off or not-yet-answered sends never surface as zero-response rows.