Changelog
Follow up on the latest improvements andΒ updates.
RSS
You can now create, edit, and delete core Chili Piper configuration through the API and MCP, not just read it.
What's possible
Full config management (create / edit / delete) is live for:
- Scheduling links
- Handoff routers
- Distro routers
- Concierge routers
- Web Experiences
Meeting Types got deeper editing too: update the default location and conferencing details, associate Reminders, and set whether a Meeting Type is shared across the whole Workspace or with specific Teams.
Also launched
- Chat logs and conversation history, pull session and conversation history programmatically.
- API request logsnow let you filter by auth method and caller email, and MCP appears as a method option.
- Paginated availability endpoint(slots-v2) for cleaner slot retrieval
There are a lot of possible configuration combinations across flows and journeys, so if you hit something unexpected, please email support@chilipiper.com.
Happy building!
A batch of quality-of-life improvements to our Web Expereinces are now live for everyone.
In the journey builder
- View Logs, one click. A new 'View Logs' button takes you straight to that flow's logs, pre-filtered, matching what Distro and Concierge already have.
- Dynamic tags- you can now insert dynamic tags in the 'Welcome Message' node, the 'Chat AI Fixed Greeting', and the 'Send a Message' node. Use 'Welcome Message' and 'Fixed Greeting' when the detail is known up front (via smart parameters or a returning guest), and 'Send a Message' once the detail's been collected earlier in the journey, such as via a S'end Data Field' node.
- Assign To, tidied up. We renamed the option and removed two route-to choices that had no effect. You can now assign to an Individual, or to a Team or Team Member via Round Robin (through a Record Distribution).
- Dev Mode has a home. Dev Mode is now a toggle under the β― menu, and the Ctrl+Shift+D shortcut still works.
In the Scheduling and Offer widgets
- Resume booking after reload (Scheduling experience). If a visitor submits their email and then refreshes the page, the widget picks up where they left off, straight to the calendar step.
- Browser autofill (Scheduling and Offer experiences). Fields now support browser autofill so visitors can fill them from saved values in a click.
- Email validation (Scheduling and Offer experiences). Malformed emails are caught inline with "This email is invalid" before anything's submitted, matching the chat lead form.
- Dark backgrounds fixed (Scheduling and Offer experiences). Typed text in the email field is now legible on dark-background experiences.
Meeting Reminders can now be sent from the host or booker's own email address, not just the generic reminder@yourdomain.com. To the guest, the Reminder reads as a normal email from the person they're meeting, and replies go straight back to that person.
Before you start
This requires a verified custom email domain. Once your domain is verified, the Send From options appears in the Reminder editor. For help setting up a custom email domain, check out this help article.
How it works
- In the reminder editor, go to Send From and choose Host, Booker, or No-reply email address.
- If the host's email is on your verified custom domain, the reminder sends from their real address (e.g. nicolas@yourdomain.com), DKIM-signed by the domain.
- If the host is on a different domain than the verified one, the reminder falls back to reminder@your-verified-domain rather than sending from an address the domain can't authenticate. Reply-to still points to the host, so replies reach them either way.
You can now keep your Hosts' and Reps' email addresses off the invites external guests receive.
Why it matters
- Guests stay in your booking and support flow instead of emailing reps directly.
- On multi-assignee, group, and round robin links, internal emails stay hidden from the guest.
What's changed and why
Normally, the calendar invite for a booked meeting is created by the Host's own Google or Microsoft calendar, so the host's email address is visible to every external guest. Guests can lift that address and email the rep directly instead of going through your intended booking or support flow. There's now a way to prevent that.
How it works
Select the new guest notification mode, Send an email confirmation, on a Team or Personal Meeting Type. When it's on:
- External guests receive an email from Chili Piper with an ICS calendar attachment instead of a Google/Microsoft invite. The ICS lists only the external attendee - the host, booker, and assignees never appear in it.
- Internal attendees still get a normal calendar event between themselves, with external guests removed from it.
- You choose where guest replies go: Host, Booker, or No-reply. With No-reply, internal email addresses are also hidden on the booking confirmation page.
- If you have a custom email domain configured, the email comes from No Reply <noreply@yourdomain.com>. Otherwise it comes from Chili Piper <notifications@chilipiper.com>.
Things to note
- Applies to new bookings only, changing the mode doesn't affect already-scheduled meetings.
- How the ICS renders (auto-add vs. manual import) depends on the guest's email client, so it's not identical to a native calendar invite.
- The confirmation email template can't be customized (yet π).
Admins can now see meeting activity across the entire org, including personal meetings, in a single report in the Command Center.
Why it matters
Meetings scheduled through Personal Links were previously invisible to admins, and Workspace meetings were housed within each individual Workspace Center. That meant organization-wide numbers were incomplete. The new Meetings Report tab in the Command Center brings everything together in one place, so the volume and activity you see reflect what's actually happening across your organization.
What's changed
- See every meeting - from all Workspaces alongside personal meetings - in one table. A WorkspaceName column shows the workspace for workspace-scoped meetings, and a Personal badge marks personal ones
- Filter by meeting type. The filter splits into Personal Meeting Types and Admin meeting types (grouped by workspace), so you can mix and match across both
- Filter by assignee through workspace β team β user
Find it in Command Center > Reports.
Workspace Managers now have a Users table under Assets > Users that shows only users in that Workspace.
What's changed and why
Until now, the only Users table was the organization-wide one in the Command Center. Workspace Managers could open it and edit organization-wide roles and licenses - including demoting Admins.
We've made 2 changes to address this:
- Workspace Managers get a dedicated Users table under Assets > Users
- The Command Center Users table is now Admin-only β Workspace Managers no longer have access to it
What's in the Workspace table?
- Role, Licenses, and Workspaces columns are read-only (even for a full Admin viewing it this way)
- Teams are editable by an Admin or a Workspace Manager
- Bulk actions, the "Open" user-details view, and "Remove user" are hidden
The Chili Piper MCP and Edge API keep getting stronger. Here's the latest round of improvements:
- Distro Logs- the Distro log table is now available via the API. For every record you get the router, the outcome (routed / no-match / error), who it was assigned to, and how they were picked, filterable by status and distribution method.
- Per-rep outcome stats in the distribution list. The final piece for a full API equivalent of the in-app Distribution table. Each user in a distribution now returns outcome counts, assigned, cancelled, no-show, and reassigned in / out.
- See who's calling your API and MCP. The Request Logs view (Integrations β API & Credentials β Logs) now includes a Caller column, the user for MCP calls or the token name for Edge API calls, alongside method, path, status, duration, and auth method. A clean audit trail of your own API and MCP usage.
- Render and validate forms before submit. scheduling-link-init now returns metadata for every guest-form field, its reference, whether it's required / optional / hidden, and its data type. Anything built on the API can render and validate the form up front instead of failing at submit time on a missing field.
- MCP OAuth now works with managed gateways. OAuth sign-in for our MCP now supports managed MCP gateways (such as Runlayer) that broker sign-in on behalf of an entire company. If you route MCP access through a central gateway, that's now supported.
Connect your LinkedIn Lead Gen Forms to Chili Piper so prospects can book a meeting the moment they submit your form.
LinkedIn passes the prospect's email, first name, and last name into Chili Piper, so they go straight to picking a time instead of filling in their details again.
Why it matters
- Speed to lead - immediate opportunity to book a meeting instead of following up manually later
- You're paying good money for those clicks. Offering the chance to book a meeting now makes your ad budget work harder
- Another entry point into your funnel
How it works
- A prospect opens your Lead Gen Form from a LinkedIn ad. LinkedIn pre-fills the form from their profile
- After they submit, the confirmation invites them to book an appointment
- Clicking Book now opens your Chili Piper booking experience with the prospect's email, first name, and last name already passed through
- Concierge qualifies and routes the prospect to the right rep, and they pick a time. With a ChiliCal Scheduling Link, the prospect books directly with the rep or team the link belongs to.
Chili Piper is the only company with a direct integration to LinkedIn Lead Gen Forms.
Check out the support article here for more.
You can now enrich Salesforce fields directly inside a Distro flow before routing.
Use cases
- Lead/Contact form submissions β enrich non-Concierge form fills (trial sign-ups, eBook downloads, webinars) before routing
- Bulk list uploads β enrich post-event lead lists before dedupe and routing
- Periodic refreshes β refresh routing criteria on existing records using Schedule Trigger
How it works
Add the Enrich node between the Entry Rule (and any Delay) and the first Routing Rule, CRM Matching, or Duplicate Match node. Inside the node, pick the Salesforce field to enrich and the enrichment waterfall to use. The Provider and waterfall configurations are the same as Concierge and Chat.
The Overwrite toggle controls existing values only:
- Off β we only write the enrichment value when the Salesforce field is empty
- On β we always overwrite the existing Salesforce value
After enrichment, routing rules evaluate against the updated Salesforce values, so you can route on what you just enriched.
The Enrich step appears inline in the log. For each field, you'll see the SFDC field, the previous SFDC data (or "No results found"), the enrichment data, whether Overwrite was on, and the new SFDC data.
Limitations
- Lead and Contact routers only β Account routers to follow
- Enrichment values aren't available in variables yet β you can route on enriched data via SFDC rules, but you can't reference the enrichment output directly in variables (e.g. for notification templates) - will follow...
Learn more here
Spam Checker is now live in Chat! The same checks that filter spam form submissions in Concierge now run inside your Chat Journeys β so bots and fake emails get caught mid-conversation, before they ever reach a rep's calendar.
Two use-cases:
- Protect rep calendars β gibberish, disposable, and role-based emails are filtered out before scheduling is ever offered
- Quiet handling β continue the conversation for flagged visitors without offering scheduling, so spammers never learn they were caught
How it works
- Add the Spam Checker node to your Journey after the visitor's email is collected
- The conversation branches on the result: Not Spam continues to qualification and scheduling, Spam follows whatever path you build for it
- Optionally write the score to the Spam Score data field and map it to your CRM
Things to note
- The node needs the visitor's email, so it must sit after an email collection step
- Checks, weights, and thresholds are configured in the same Spam Checker settings you already use for forms β one configuration covers both
Learn more here
Load More
β