Concierge Snippet and JS API – Chili Hub

Who can use this feature?

Available on Concierge

Available to Admins Workspace Managers

Billing Center Get a Demo

With the Concierge Router, we have these options for deployment and use.

Embedded Snippet: Insert it in your form and post-form pages. Everything will work the same way as before, except that your qualified prospects will be prompted to book a meeting with the correct calendar at the right time.
JS API: Call Chili Piper from your JavaScript code to control the workflow fully.
REST API: Server to Server. Most Advanced—This method is used primarily for in-app use cases or where including third-party scripts is impossible. Please contact your Customer Success Manager or see this article for more about this method.

In this article, we will cover the Embed Snippet, Javascript Snippet, and additional API options available for use.

If you haven't been upgraded to the Demand Conversion Platform yet, you may want to check this article instead.

Embedded Snippet
JS API
API Options

Getting Started

The first step is accessing the router's embed tab. If you need some guide to access the tab, please see this guide.

Embedded Snippet

Chili Piper's embed snippet collects data from the form type specified; you will need to know which form you are integrating Concierge with so you can select it from the available options. If the form is standard HTML, you can use our HTML Form option.

Below is a sample of the code snippet to insert:

<script src="https://chilipiper1.chilipiper.in/concierge-js/cjs/concierge.js" type="text/javascript"></script>
<script>
   ChiliPiper.deploy("chilipiper1", "test-router", {"formType":"HTML"})
</script>

where

<script src="https://chilipiper1.chilipiper.in/concierge-js/cjs/concierge.js" type="text/javascript"></script>

The above is unique to each Chili Piper tenant and installs Chili Piper on your page, while the script that triggers the configured router is below.

ChiliPiper.deploy(subdomain, router, options)

domain = domain or subdomain of account
router = API name of the router
options = additional options (see below)

JS API

If you want to use JS API for your inbound routing with Concierge, you must enable the option below in your Router's Trigger to have this option enabled!

In the Embed tab, go to the On a Website and/or Web App option:

Here, you'll need to select a trigger type, and afterward, you will find the JS snippet or Custom API snippet that you can use to route your prospects inside your application.

Below is a sample of the JS API:

<script src="https://chilipiper1.chilipiper.in/concierge-js/cjs/concierge.js" type="text/javascript"></script>
<script>
  ChiliPiper.submit("chilipiper1", "test-router", {
     trigger: 'ThirdPartyForm', 
     lead: {
       'Email': '', // replace the value with the value for Email
       'First Name': '', // replace the value with the value for First Name
        }
  });
</script>

where

<script src="https://chilipiper1.chilipiper.in/concierge-js/cjs/concierge.js" type="text/javascript"></script>

The above is unique to each Chili Piper tenant and installs Chili Piper on your page, while the script that triggers the configured router is below.

ChiliPiper.submit(subdomain, router, options)

See more about the deployment of the in-app here.

API Options

These API options would work with either the ChiliPiper.deploy() or ChiliPiper.submit() functions.

const options = {
formId: string,
formIds: array,
domain: string,
router: string,
trigger: string,
lead: {[Object]},
onSuccess: function,
onError: function,
onClose: function,
onRouted: function,
closeOnOutside: boolean,
onRouting: string,
onDisqualified: string,
locale: language_code,
event: {[Object]},
accountId: string,
caseId: string,
opportunityId: string,
campaignId & status: string,
domElement: string,
attendees: string,
disableRelation: boolean,
meetingTypeId: string

formId: string

It is helpful when you have multiple form elements within 1 page to prevent the Chili Piper snippet from firing upon submitting the wrong form. If you add this option, your snippet will ONLY execute when the form you specify is submitted.

For example, you wouldn't necessarily want Chili Piper to load when a customer submits a search bar query or newsletter sign-up.

This works with only the ChiliPiper.deploy() function.

Sample below:

<script>
   ChiliPiper.deploy("domainName", "routerName", {
      "formType":"HTML",
      "formId":"form-123"
   })
</script>

formIds: array

It is helpful when you have multiple form elements within 1 page to allow the Chili Piper snippet to fire upon submitting specific forms and NOT all forms on the page. If you add this option, your snippet will ONLY execute when the forms you specify are submitted.

This works with only the ChiliPiper.deploy() function.

Sample below:

<script>
   ChiliPiper.deploy("domainName", "routerName", {
      "formType":"HTML",
      "formIds":["form-123","form-456"]
   })
</script>

trigger: string

It is helpful when running Chili Piper via In-App or from your JavaScript code to control the workflow fully. The three available options currently are:

ThirdPartyForm
InAppButton
RouterLink

This works with only the ChiliPiper.submit() function.

Sample below:

<script>
   ChiliPiper.submit("domainName", "routerName", {
     trigger: 'InAppButton',
     lead: {
       'Email': 'test@test.com',
       'First Name': 'test'
       }
   });
</script>

lead: {[Object]}

It is helpful when running Chili Piper via a button click or within your web app. Pass parameters directly to ChiliPiper.submit().

Sample below:

<script>
   ChiliPiper.submit("domainName", "routerName", {
     trigger: 'ThirdPartyForm',
     lead: {
       'Email': 'test@test.com',
       'First Name': 'test'
       }
   });
</script>

onSuccess: function

This will call a function after a successful booking. A time-specific redirect can be defined within the Router UI under "Router Redirect," this option is not always required and is used with more custom form integrations.

A use case could be for tracking purposes, such as the sample below:

<script>
   ChiliPiper.submit("domainName", "routerName", {
     trigger: 'ThirdPartyForm',
     "formId":"form-123",
     onSuccess: ()=>{
        window.dataLayer = window.dataLayer || [];
        window.dataLayer.push({
           'event': 'meeting_booked',
           'formLocation': 'request_demo',
          });
       }
   });
</script>

onError: function

This will call a function when a lead is submitted but does not match any queue rules and cannot be routed. Thus no calendar is displayed. This is usually when someone is disqualified from booking. A redirect can be/might have been specified within the Router UI under "Router Redirect," so this option is not always required and is used with more custom form integrations.

A use case could be for logging a console message, such as the sample below:

<script>
   ChiliPiper.submit("domainName", "routerName", {
     trigger: 'ThirdPartyForm',
     "formId":"form-123",
     onError: ()=>{
         //Log successful submission but no match
         console.log(“We didn’t find a match”);
        }
   });
</script>

onClose: function

This will call a function when a lead is submitted and displays the option to book (meaning the lead has qualified for a meeting) but exits the booking module. A redirect can be specific within the Router UI under "Router Redirect," so this option is not always required and is used with more custom form integrations.

A use case could be for logging a console message, such as the sample below:

<script>
   ChiliPiper.submit("domainName", "routerName", {
     trigger: 'ThirdPartyForm',
     "formId":"form-123",
     onClose: ()=>{
         //Log successful submission but Closed calendar
         console.log(“Prospect didn't complete booking”);
        }
   });
</script>

onRouted: function

This will call a function when Chili Piper has received a lead's submission and a routing attempt has been made, whether successful or not. This will occur before the onSuccess, onError, or onClose functions are executed to indicate routing has begun.

A use case could be for logging a console message, such as the sample below:

<script>
   ChiliPiper.submit("domainName", "routerName", {
     trigger: 'ThirdPartyForm',
     "formId":"form-123",
     onClose: ()=>{
         //Log successful routing after submission
         console.log(“Prospect was routed”);
        }
   });
</script>

closeOnOutside: boolean

This is a DOM listener option. By default, it is set to false, and clicking the "X" within the booking module will close the calendar UI. When you select the option closeOnOutside: true, this will allow the Chili Piper booking module to be "closed" when the lead clicks outside the booking frame. Any redirect settings for those who don't book or the onClose: function will be triggered when the lead clicks outside the module. We recommend against enabling this option for conversion purposes to prevent accidental closures unless there is a specific reason.

This works with either the ChiliPiper.deploy() or ChiliPiper.submit() functions.

Sample below:

<script>
   ChiliPiper.deploy("domainName", "routerName", {
      "formType":"HTML",
      closeOnOutside: true,
   })
</script>

onRouting: string

This will call a function when Chili Piper has received a record submission and a routing attempt is being made. This will occur before the onRouted, onSuccess, onError, or onClose functions are executed to indicate routing is in progress.

<script>
ChiliPiper.submit("domainName", "routerName", {
trigger: 'ThirdPartyForm',
"formId":"form-123",
  onRouting: ()=>{
  //Hide the loading animation
  document.querySelector('.chilipiper-frame').style.display = 'none';
  }
});
</script>

onDisqualified: string

This will call a function when Chili Piper has received a record submission and disqualified it.

<script>
ChiliPiper.submit("domainName", "routerName", {
trigger: 'ThirdPartyForm',
"formId":"form-123",
 onDisqualified: ()=>{
 //Log successful submission but no match
 console.log(“We didn’t find a match”);
 }
});
</script>

locale: language_code

This allows you to force a specific language in which you would like to serve the Chili Piper calendar for the respective page or user.
Here are all the supported languages and respective locale codes to use when passing this parameter to us.

This works with either the ChiliPiper.deploy() or ChiliPiper.submit() functions.

Sample below:

<script>
   ChiliPiper.deploy("domainName", "routerName", {
      "formType":"HTML",
       locale:"de_DE",
   })
</script>

The example above would force the calendar to render in German, regardless of the users' browser settings, per the { locale: "de_DE" } option.

event: {[Object]}

Using the following format, you can pass custom field values to the Event object. This is useful for mapping fields to a Lead/Contact and an Event during the booking process.

This works with either the ChiliPiper.deploy() or ChiliPiper.submit() functions.

Sample below:

<script>
   ChiliPiper.deploy("domainName", "routerName", {
      "formType":"HTML",
       event: { your_custom_field__c: "your_custom_field__c_value" },
   })
</script>

accountId: string

The SFDC ID of an Account. Forces a Contact to be created under the account passed to us. Accepts both 15 and 18 Digit Salesforce AccountId values.

This works with either the ChiliPiper.deploy() or ChiliPiper.submit() functions.

Sample below:

<script>
   ChiliPiper.submit("domainName", "routerName", {
     trigger: 'ThirdPartyForm',
     lead: {
       'Email': 'test@test.com',
       'First Name': 'test',
       'Last Name': 'doe',
       },
     accountId: "0015c00002FIJ7wAAH",
   });
</script>

More details on how this works:

If accountId is added to JS options, but there’s no update/create record node in the router on this path, Chili Piper will not create a contact. Please make sure you add the Update/Create node in your router flow builder.
If a Lead or Contact Exists, but the Contact is in another Account, it will create a net new Contact under the accountId passed to us. (a purposeful duplicate)
If a single Contact already exists under that Account (by email), we will use that Contact and not create a new one.
If multiple Contacts exist with that email address, one of which is associated with the AccountId in question, we will use the Contact ID from the accountId value passed.

caseId: string

The SFDC ID of a Case. Forces an Event to be associated with the Case passed to us. Accepts both 15 and 18-digit Salesforce AccountId values.

This works with either the ChiliPiper.deploy() or ChiliPiper.submit() functions.

Some considerations to note:

If there is no Event Creation Node in your Concierge Router, we will not relate the Event with Cases.
We only relate to Cases if one Contact with the same email exists there. If it only has Leads, we won’t be able to relate the Event with the Case due to a Salesforce limitation.

Sample below:

<script>
   ChiliPiper.submit("domainName", "routerName", {
     trigger: 'ThirdPartyForm',
     lead: {
       'Email': 'test@test.com',
       'First Name': 'test',
       'Last Name': 'doe',
       },
     caseId: "5000W00001DS2Pm",
   });
</script>

opportunityId: string

The SFDC ID of an Opportunity. Forces an Event to be associated with the Opportunity passed to us. Accepts both 15 and 18-digit Salesforce AccountId values.

This works with either the ChiliPiper.deploy() or ChiliPiper.submit() functions.

Some considerations to note:

If there is no Event Creation Node in your Concierge Router, we will not relate the Event with Opportunities.
We only relate to Opportunities if one Contact with the same email exists there. If it only has Leads, we won’t be able to relate the Event with the Opportunity due to a Salesforce limitation.

Sample below:

<script>
   ChiliPiper.submit("domainName", "routerName", {
     trigger: 'ThirdPartyForm',
     lead: {
       'Email': 'test@test.com',
       'First Name': 'test',
       'Last Name': 'doe',
       },
     opportunityId: "0061U000004opKiQAI",
   });
</script>

campaignId & status: string

The SFDC Campaign Id to be associated to the prospect (Lead/Contact) and the campaign member status value. Accepts both 15 and 18-digit Salesforce AccountId values. This works with either the ChiliPiper.deploy() or ChiliPiper.submit() functions.

<script>
ChiliPiper.submit("domainName", "routerName", {
trigger: 'ThirdPartyForm',
lead: {
 'Email': 'test@test.com',
 'First Name': 'test',
 'Last Name': 'doe',
 },
 campaignId: "7014x000001CWxt",
 status: "Responded",
});
</script>

domElement: string

It is valuable when you want to embed the calendar within a page or the modal window to load within a specific element of your site (i.e., inline div) rather than as a popup.

domElement value can be either a selector (id, class, etc.) or a direct reference to the dom node. It will work in either case.

domElement: "#main",

More information on this setup can be found in this article.

attendees: string

Passes an attendees list, which will add the specified emails as Guests for booked meetings.

<script>
ChiliPiper.deploy("domainName", "routerName", {
"formType":"HTML",
attendees:"email1@chilipiper.com, email2@chilipiper.com" ,
})
</script>

disableRelation:true

When you set disableRelation:true in your Concierge JS snippet, this option will "decouple" the Event record from the associated Lead or Contact in Salesforce. It removes the WhoId value from the Event record, unlinking it from specific Contacts or Leads.

Consider using this setting only if you have a custom workflow in Salesforce for associating your Events.

We also recommend discussing this option with your Chili Piper CSM to ensure it aligns with your Salesforce integration needs.

meetingTypeId:Id

You can also "force" a meeting template to be used in your booked meetings, even though you have a different one associated with the Scheduling Link being used.

Be careful, as all settings associated with the Meeting Type you use will also be taken into consideration during the booking process.

To get your Meeting Type ID to be used, navigate to the Meeting Types page under the Assets menu and open the Meeting Type you want to use.

You will be able to find the Meeting Type ID in the browser's URL:

The syntax would look like

meetingTypeId: "158336c7-5b15-4bd5-b48e-6887231b8b55"

Who can use this feature?

Table of Contents

Getting Started

Embedded Snippet

JS API

API Options

formId: string

formIds: array

trigger: string

lead: {[Object]}

onSuccess: function

onError: function

onClose: function

onRouted: function

closeOnOutside: boolean

onRouting: string

onDisqualified: string

locale: language_code

event: {[Object]}

accountId: string

caseId: string

opportunityId: string

campaignId & status: string

domElement: string

attendees: string

disableRelation:true

meetingTypeId:Id

Related articles