Setting Up Webhooks

Webhooks let bluebarry instantly send quiz data to your other tools.

Think of it as: someone completes part of a quiz, and your email tool, CRM, or automation flow can react right away.

Use cases for webhooks

Common ways teams use webhooks:

1. Send abandoned-result or post-quiz email sequences
2. Sync quiz answers and profile traits to your ESP or CRM
3. Trigger flows based on specific answer choices
4. Store recommendation outcomes in BI or analytics tools

Available webhook topics

In bluebarry, you can choose from three webhook triggers:

• question.answered – Sent each time someone answers a question. You can track all quizzes, one quiz, one question, or even one specific answer.
• result.viewed – Sent when someone reaches the results page. You can track this for all quizzes or one specific quiz.
• profile.updated – Sent when bluebarry updates a visitor profile based on quiz behavior. You can track this for all quizzes or one specific quiz.

A profile in bluebarry is the visitor record built from quiz interactions (for example email, answer-based properties, consent, and product recommendations).

How topics work (in bluebarry and API)

These topic formats are the same ones bluebarry uses in the app. If you create webhook subscriptions through the API, use these exact topic values:

• question.answered
• question.answered.{quizId}
• question.answered.{quizId}.{questionId}
• question.answered.{quizId}.{questionId}.{answerId}
• result.viewed
• result.viewed.{quizId}
• profile.updated
• profile.updated.{quizId}

Replace placeholders with real IDs. For example, result.viewed.{quizId}becomes result.viewed.6f7f3ad1-0b8e-4e89-bd8f-2c625b3c9a11. Remove the curly braces and insert the actual value.

To find your quizId in bluebarry: open the quiz funnel and go to its Design page. The URL looks like /quizzes/{quizId}/design. The middle part is your quiz ID.

Understanding the data structure

The webhook uses your internal names from bluebarry. This keeps everything consistent but means you need to set these up properly:

• Internal question names – Change these in your funnel's left-hand menu where all your question settings live
• Internal answer values – Update these in the "Flow" section of your quiz builder

Payload overview

Each webhook sends a JSON payload, and the fields depend on which trigger you chose. In bluebarry, click Example payload to preview exactly what your team will receive. You can find this button in Dashboard → Integrations → Webhooks: while creating a webhook (after selecting a topic type), and on each saved webhook card.

• question.answered: selected answer details, answer value/text, and consent signal.
• result.viewed: session context, answered questions, and recommended products.
• profile.updated: profile details (like email and properties), consent info, and recommendations.

For result and profile webhooks, bluebarry can also include product attributes such as price, category, and other mapped product data.

Delivery and retries

• bluebarry sends webhook data to your URL right after the trigger happens.
• A delivery is marked successful when your receiving endpoint confirms it was accepted.
• Every attempt is logged under each webhook in bluebarry with status and timestamp.
• You can retry failed deliveries manually from Delivery Attempts.
• After 5 failed deliveries in a row, bluebarry automatically disables that webhook for safety.

Setting up a webhook

1. Go to Dashboard → Integrations → Webhooks.
2. Click Create webhook.
3. Give it a name and choose a topic type.
4. Optionally scope it to a specific quiz, question, or answer (depending on topic type).
5. Paste the receiving URL from your tool (for example Make, Zapier, Klaviyo middleware, or your CRM endpoint).
6. Save it, run a quick test quiz, and confirm the data arrives correctly.

Testing and troubleshooting

Use a request inspector like webhook.site to preview incoming data before connecting your live automation.

• Use bluebarry's Example payload to map fields before building your workflow.
• Check Delivery Attempts to see whether each send succeeded or failed.
• If a webhook gets disabled after repeated failures, fix the receiving step and turn it back on.