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 withPOST /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.
Cache-Control: private, no-store, so shared links are never
cached.
Submit a survey response
POST /api/v1/public/surveys/{token}/submitstring
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.
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.
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 backskipped, never double-sent.
List non-responders
GET /api/v1/surveys/{id}/non-respondersstring
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.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}/remindstring
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.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/scorecardsstring
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.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.