Can I post new survey responses into Slack in real time?

Yes, although it takes a small amount of setup on your side. There is no native Slack integration and no published Zapier connector for Conjointly, so the work happens in an automation tool such as Zapier or Power Automate.

There are two ways to trigger it. The more common one uses the completion redirect:

1. Redirect each respondent to your automation flow when they finish the survey, passing their participant ID in the query string.
2. Have the flow call the Conjointly API to fetch that respondent’s answers.
   • In Zapier, start the Zap with a Webhooks by Zapier catch hook, then add a Webhooks by Zapier custom request action to call the API, then a Slack action to post the message.
   • In Power Automate, use a When an HTTP request is received trigger, an HTTP action to call the API, then a Post message in a chat or channel action.
3. Have the flow post the result into Slack and then send the respondent on to a thank-you page.

Either way you get a genuine per-response trigger, so you do not need to poll the API on a timer. The alternative, firing from inside the survey with JavaScript, notifies you before the respondent finishes.

How do I pass the participant ID to the flow?

There is no webhook that Conjointly pushes to on each new response. The equivalent trigger is the completion redirect, which fires in the respondent’s browser the moment they finish the survey.

Redirect URL fields accept formulas, and the respondentInfo() function gives you the participant ID. Use concat to build the URL:

concat("https://hooks.zapier.com/hooks/catch/123456/abcdef/?participantId=", respondentInfo("id"))

Replace the hook URL with your own catch hook or Power Automate HTTP trigger URL. Your flow then reads participantId from the query string and uses it in the API call.

The respondent’s browser lands on whatever your flow returns, and a raw catch hook typically returns a short JSON status message. Configure your flow to respond with a redirect to your own thank-you page so respondents see something sensible.

Which endpoint returns the scores and open-text comments?

Use the survey answers endpoint, passing the experiment ID and the participant ID from the query string:

Request: GET https://api.conjoint.ly/api/experiments/experimentId/quality-checker/survey-answers/participantId

See how to get survey answers for a respondent via API for the full request and response reference, and Authentication for the token header your flow needs to send.

A few points worth knowing:

• There is no NPS-specific endpoint. A Net Promoter Score question and its open-text follow-up are both ordinary survey questions, so both come back in this one response, alongside every other question the respondent answered.
• Answers arrive in one of two shapes, depending on questionType. Questions with options return an items array, where the option the respondent chose has "value": 1. Everything else returns a single answer string. Your flow needs to handle both.
• The two you want for this use case are both single-string answers. An NPS question ("questionType": "nps") gives the rating with the top of the scale, for example "5 / 10", so split on the slash to get the score. An open-text question ("questionType": "capture") gives the comment as typed.
• The response also includes elements that are not really answers, such as intro screens and conjoint blocks. Pick out the questions you want to post by additionalQuestionId, rather than posting everything you receive.
• Match questions across respondents using additionalQuestionId rather than order or questionText, so your Slack message keeps working if the questionnaire is edited.
• questionText usually contains HTML markup, such as wrapping <p> tags. Strip it before putting it in a Slack message.
• Make one test call with a real participant ID and inspect the payload before you finalise the field mapping in your flow, since the shape depends on the question types you have used.
• This endpoint reads current data directly, rather than going through the cached report exports.

The following will not (in all cases) trigger a notification:

• Respondents who abandon the survey never reach the completion redirect, so partial responses are not sent.
• Screened-out and low quality responses follow their own redirect fields. Leave those blank, or point them elsewhere, if you only want completes in Slack.
• If anonymisation is enabled for the study, some respondent properties are unavailable, although the participant ID itself remains available.

The bulk respondent information export covers the same ground for whole-of-study analysis, but it runs as a job and returns a file, which makes it a poor fit for a per-response Slack notification.

How often can the API be called, and is it truly real time?

With the redirect approach, the call happens once per completed response, within a second or two of the respondent finishing, so the delay is negligible.

If you poll instead, be aware that:

• Polling frequency is not the limiting factor for freshness. The answers are available as soon as the response is recorded, so a short polling interval mostly means more calls that return nothing new.
• Conjointly does not publish a hard rate limit, but treat the API as a shared resource. Once a minute is ample for a notification use case, and you should handle non-200 responses gracefully rather than retrying in a tight loop.
• Polling requires you to track which participant IDs you have already seen, which the redirect approach avoids entirely.

Another option: fire from inside the survey

The completion redirect only fires when someone reaches the end of the survey. If you want to be notified sooner, or at a particular point in the questionnaire, add a calculated variable with its Type set to JavaScript. Its test() function runs in the respondent’s browser when they reach that point in the survey flow, so it can call your automation tool directly:

function test() {
    navigator.sendBeacon("https://hooks.zapier.com/hooks/catch/123456/abcdef/");
    return "notified";
}

Weigh this against the redirect approach:

• It fires mid-survey, so you hear about a response before the respondent finishes, and you can trigger at any point in the flow rather than only at the end.
• The code runs in the respondent’s browser, so everything in it is visible in the page source. Never put an API token there.
• Getting the participant ID into the JavaScript field is not documented, so if your flow needs to call the API for that specific respondent, the redirect is the more predictable route.
• A calculated variable must return a value, which is then stored against the respondent.

Important note

Keep your API token out of the survey link and out of anything the respondent can see. The token belongs in your flow’s request headers only.

If you would like a hand setting this up, get in touch and we will help.