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, 0–10. 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 1–8760. Bad values fall back to the default rather than erroring, so the list stays loadable.
integer
Page size, 1–200, 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 1–8760.
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, 1–200 (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.

Worked response envelopes (per operation)

The envelopes below are the response contracts for the individual survey operations the generated page enumerates. Each is hand-authored against the real reply shape the route returns — use them as the integration target for the matching <Note> route. For the full VoC playbook (sentiment, themes, drivers, and the NPS trend over time), see guides/surveys-voc.mdx.

List all survey templates

GET /api/v1/surveys

Get a single survey template

GET /api/v1/surveys/{id}

Create a survey template

POST /api/v1/surveys

Update a survey template

PATCH /api/v1/surveys/{id}

Delete a survey template

DELETE /api/v1/surveys/{id}
Returns 204 No Content with an empty body. A successful delete carries no JSON envelope — the response is the status alone. A 404 is returned when the template does not exist.

List non-responders

GET /api/v1/surveys/{id}/non-responders

Send a reminder wave

POST /api/v1/surveys/{id}/remind
When nobody is eligible yet, the same shape returns { "requested": 0, "sent": 0, "skipped": 0, "reason": "no_non_responders" } under data.

Send a survey to an audience

POST /api/v1/surveys/{id}/send

Aggregate rollup

GET /api/v1/surveys/{id}/results

Voice-of-Customer analytics

GET /api/v1/surveys/{id}/voc

Benchmark percentiles

GET /api/v1/surveys/{id}/benchmark
The ?vertical= query parameter picks the peer group (for example, ?vertical=telecom, ?vertical=retail, ?vertical=saas); the chosen group echoes back in meta.vertical so the response is self-describing.

Validation errors worth branching on

Survey writes validate the body before any row is read. A failed validation returns 422 VALIDATION_ERROR with error.details.issues listing each rejected field, so you can name the exact field to fix instead of resending the same body:
422
Branch on error.details.issues[].field, fix that field, and resend intentionally — a blind retry of the same body repeats the 422. For the worked end-to-end failure flows these branches plug into, see the error handling guide.