There are two ways to tell another system how a survey session ended. Send the respondent's browser to a URL that encodes the outcome, or have one server call the other directly. Most integrations use both. The useful question is which one you believe when they disagree.
Browser redirects
A redirect moves the respondent to the next page and carries the outcome in the URL. It is unavoidable: the respondent has to go somewhere when the survey ends.
Good for: any survey platform can do it, no server development, and it returns the respondent to their panel at the same time.
Breaks when:
- The respondent can see and edit the URL, unless it is signed.
- The respondent closes the tab, loses signal, or an extension blocks the redirect. The outcome never arrives.
- Someone saves the URL and opens it again later.
Server-to-server calls
A postback, or a status API call, goes from one server to another. The browser is not involved.
Good for: the respondent never sees it, so nobody can edit it. It still arrives when the tab is closed. And it can be retried if the receiving server is down.
Breaks when:
- The sender has no server that knows the outcome.
- The receiving endpoint is not authenticated, so anyone can call it.
- Retries deliver the same outcome twice to an endpoint that is not idempotent.
How ResearchDart uses each
Buyer to ResearchDart. The survey redirects to an endlink. For stronger protection the project can require signed endlinks, or the buyer can report the outcome with the status API. Whichever arrives first is recorded and the other is ignored. If you use the API, call it before redirecting the respondent, so the server outcome is always the one recorded.
ResearchDart to supplier. The respondent is redirected to the supplier's URL for that outcome, and at the same moment ResearchDart sends a postback to the supplier's server. Failed postbacks are retried after 1, 5, 30, 120 and 720 minutes, six attempts in total.
When they disagree
Pick one authority and write it down. On ResearchDart the first outcome recorded is final, whatever the channel. That rule is dull and it ends arguments.
Make receivers idempotent. A retry that follows a slow success can deliver the same session twice. Key your endpoint on the session ID and ignore repeats.
Reconcile from records, not from redirect logs. The supplier transactions API returns what was actually recorded, including sessions whose redirect never arrived and, after cleaning, any GDQ-coded reversals.
What we would choose
| Situation | Approach |
|---|---|
| Survey platform can neither sign nor call an API | Plain endlinks, session checks, minimum LOI. Accept the residual risk. |
| Platform can run server-side code | Signed endlinks |
| You control a backend that sees outcomes | Status API before the redirect |
| Supplier with a server | Redirect for the respondent, postback for crediting |
Redirects are how people move. Server calls are how systems agree about money. Mixing up those two jobs is where most reconciliation work comes from.