JavaScript Integration
If you run your survey on your own JavaScript stack rather than on a platform like Decipher or Alchemer, there are two shapes an integration can take. They differ in where the Quality Tools run and, because of that, when you send us data.
Pick the one that matches your flow — the rest of this section follows from it.
Two ways to integrate
A — In-survey: the tools run on every page
The Quality Tools live inside the survey itself, so identity and scores are available throughout the interview. You send once early, and again at the end.
B — Router or redirect: the tools run once, at entry
The respondent only passes through your page on the way to a survey. You run the tools once, get a
requestId, send the first record, and redirect. The second send happens when they come back.
Which one are you?
| A — In-survey | B — Router / redirect | |
|---|---|---|
| Toolbox runs | On every page of the survey | Once, at entry |
| You get scores | Throughout the interview | At entry, then you hold them |
| First send | After the first question | Before you redirect |
| Final send | End of the interview | When the respondent returns |
| Read | In-Survey | Routers & Redirects |
Most people integrating in JavaScript are B. If you own a router, a redirect page, or any hop that sits in front of someone else's survey, that is your path — and it is the one documented in full today.
Browser or server, we do not mind — as long as the key that reaches POST /data and the
lookup stays on your server. The toolbox URL carries a key by design. Both paths
send the same two records to the same endpoint; only the timing differs.
What both paths share
Whichever shape you use, the rest is identical:
- Sending Data to DQC — the lifecycle: which status to send and when, and what a Partial needs.
- POST /data — the endpoint, every field, and what each value means.
- Integration phases — what happens after you start sending.