Skip to main content

Data out of Chameleon

A webhook is an agreed-upon method of data exchange across a secure channel. Since you will be adding a new endpoint to your backend servers to handle this webhook, is it strongly recommended that you verify the signature of any webhook requests before processing any included data. When sending a webhook to your backend Chameleon will:
  • Send a POST request to your https configured endpoints.
  • Attempt delivery right away from aws us-east, use a request timeout of 7 seconds and include a User-Agent header specific to the API version the webhook is being sent from.
  • Generate a SHA256-HMAC signature of the request body and include the signature in the X-Chameleon-Signature header
  • In case of non-200 status code, will retry a total of 9 times over 43 hours (giving you a chance to fix errors without losing track of these webhooks)
When receiving a webhook from Chameleon you should:
  • Only accept requests from Chameleon IP Addresses
  • Verify the Webhook request signature; respond with a status 400 if the signature does not match
  • Drop the request if the webhook is too old (to prevent replay attacks); respond with a status 400
  • Respond quickly with a 200 status code (or any 2xx status code)
  • Optional: Request any related data with the other APIs

Webhook topics

Looking for a different topic? We’re excited to chat about your use case! Contact us

Schema (request body)

Request headers

Verifying the Webhook

The signature is the SHA256-HMAC of your Webhook Secret and the request body. As a second step, reject the message if it was sent outside of a few minutes (in the examples below 5 minutes is used; to prevent replay attacks)

Verification Examples

Rails
Have an example from your production app to add? Submit a PR to this file and we’ll give you $25 Amazon credit via our Docs Bounty program!

Action

Each Webhook can contain an action key in the payload. It will contain contextual information about the webhook, the source of the webhook, the state of a user, etc.

Action

Applies to tour.started, tour.completed, tour.exited, survey.started, survey.completed, survey.exited, embed.started, embed.completed, embed.exited

Action

Applies to tour.snoozed, survey.snoozed, embed.snoozed

Action (helpbar.item.error)

Action (helpbar.item.action)

Action (helpbar.answer)

Payload Examples

Example ping
Typically do process Verification for this topic but nothing really to be done when topic is received. It’s simply part of how Chameleon determines active/inactive/performance of webhook endpoints.
Example response-finished
Every Microsurvey that is finished will send a webhook to this topic.
Example helpbar-answer
This is the most important HelpBar webhook; it can directly inform your roadmap for additional updated/documentation.
  • Chameleon AI Answering operates best when:
  • A headline (h2/h3) in the Help center article is relevant to the question being asked
  • Multiple inputs corroborate from different angles
  • Seeing a results_count less than 3 is an important metric to track
  • Use references to know where to make improvements
Example helpbar-search
When a User searches for "data importing" only 0 results were found. This indicates a gap in your Help center.
When a User searches for "widget categories" only 7 results were found.
Example helpbar-item-action
When a helpbar search result item is clicked (or actioned)
Example helpbar-item-error
When a helpbar search result item is clicked (or actioned) and then encounters an error processing the actions. In the example below, the script item is not working properly and should be checked
Example tour-all
A Tour is started, runs through a sequence of 1 or more Steps and finishes by being Exited or Completed. Tours by default show once to any one User but can, depending on their settings, show multiple times.
Example tour-snooze
When a Tour is snoozed it is set to come back after a certain amount of time has passed (i.e. 1 day, 2 weeks, 2 hours etc.).
Look for data.action to be an object with the information on when this snooze ends, how many hours, and how many snoozes this totals.
Example tour-button-clicked
Every Button that is clicked in a Tour / Microsurvey will send a webhook to this topic. It includes the Step and the Button configuration.
The key will be “tour”, “survey”, or “embed” depending on the Experience type.
Example embed-all
An Embed is started, runs through a sequence of 1 or more Steps and finishes by being Exited or Completed. Embeds by default show once to any one User but can, depending on their settings, show multiple times.
Example embed-snooze
When an Embed is snoozed it is set to come back after a certain amount of time has passed (i.e. 1 day, 2 weeks, 2 hours etc.).
Look for data.action to be an object with the information on when this snooze ends, how many hours, and how many snoozes this totals.
Example alert-triggered
When Experiences are in violation of the Alert conditions. The primary use case for this is to notify the person in charge of the Experience when X days have passed without activity (on something that is otherwise expected to have activity).
Experiences are either kind=tour for a Tour or kind=survey for a Microsurvey
For Tags and Environments see the "tags" and "url_groups" keys below and see Experience page.
Example survey-all
These three topics are considered lifecycle events and occur when the user is presented with or interacts with a Chameleon Microsurvey. The response.finished Webhook is only sent when we consider the user done with the Microsurvey and will no longer interact with it. A Microsurvey Response is generated when the Microsurvey Step + associated Response Step are finished; it sends a response.finished Webhook. A Microsurvey is started on the Survey Step and either completed or exited when the first step is “actioned”. It then automatically branches through a sequence of optional Response Steps and finishes with an optional Thank You Step.
The Steps corresponding to a Response Step have preset=response; The Thank You Steps have preset=thank_you
Example survey-snooze
When a Microsurvey is snoozed it is set to come back after a certain amount of time has passed (i.e. 1 day, 2 weeks, 2 hours etc.).
Look for data.action to be an object with the information on when this snooze ends, how many hours, and how many snoozes this totals.
Example demo-started
Right when the Demo is first started in this session. Chameleon calls this a Demo “run”. Demos can also sync Contact data into the CRM
For an anonymous user (e.g. on your marketing website) the data.profile will be null and demo_run.anonymous_id will be stable until local cache is cleared
Example demo-finished
This webhook topic only differs from demo.started by the addition of the following keys in the demo_run.
  1. In the demo_run, an actions array of DemoActions
  2. In the demo_run, a submissions array of DemoSubmissions with a data key of DemoSubmissionData
  3. finished_kind in the demo_run as either "last_step" or "timeout_30m" to give an indication of how this Demo was finished
It will be sent when the last step of the Demo is reached with finished_kind=last_step OR approximately 30 minutes after the last activity in the Demo and finished_kind=timeout_30m.
Example demo-reveal
This webhook topic only differs by the addition of reveal_domain, reveal_name, and clearbit_uid in the demo_run. It will be sent when the following conditions are met
  1. Clearbit Reveal is configured in your dashboard
  2. The consent_mode of the Demo was set to granted (e.g. data-consent-mode="granted" on the iframe element for the embed)
  3. A match is found to the IP address of anonymous traffic
Example demo-form-submitted
This webhook topic is meant to sync any form data to an external system; typically involving adding a new contact to your CRM. The action.submission is a DemoSubmissions with a data key of DemoSubmissionData and each data item has a field as DemoFormField and value.
Example demo-email-added
This webhook topic is meant to capture the moment when previously taken anonymous Demos receive an email address. The flow can be arbitrarily complex but typically follows one of these paths:
  1. Demos taken => Submits interest form
    1. User takes 1 or more Demos on the marketing site, help documentation, etc.
    2. In one of the Demos, the User submits a form with their email
    3. Chameleon will then update all the previous DemoRuns from [1i] (e.g. those connected with the anonymous_id)
    4. Chameleon sends one demo.email.added webhook per updated DemoRun
  2. Demos taken => Product signup
    1. User takes 1 or more Demos on the marketing site, help documentation, etc.
    2. User sign up for the product and is identified with their email address
    3. Chameleon will then update all the previous DemoRuns from [2i] (e.g. those connected with the anonymous_id)
    4. Chameleon sends one demo.email.added webhook per updated DemoRun
action.email will have email address as a copy of the email address now found in demo_run.email.