Guide to Chili Piper Webhooks: Features and Best Practices

Chili Piper custom webhooks send booked-meeting data to your systems: a prospect books a demo through a router, a rep reschedules it, or the meeting is canceled. Chili Piper handles meeting scheduling and inbound lead routing, and webhooks let you feed those meetings into a data warehouse, a CRM or an automation without polling.

This guide covers how Chili Piper webhooks are created and signed, what the payload contains, and how to run a receiver given how little Chili Piper documents about delivery.

What are Chili Piper webhooks?

A Chili Piper custom webhook is a URL plus one action type: For New Meeting, For Meeting Update or For Canceled Meeting. You create them in the Command Center under Integrations, and you can create as many as you like. Several webhooks can point at the same URL, and one action type can have several URLs.

Chili Piper signs every payload. Each request carries X-Chili-Signature, a hex HMAC-SHA256 of <X-Chili-Timestamp>.<raw body>. The signing secret is one per tenant, and Chili Piper doesn't show it in the Command Center: you request it by email from support.

Chili Piper webhook features

Feature	Details
Configuration	Command Center, Integrations > Custom Webhooks. Admins or workspace managers
Subscription model	One action type per webhook. URLs can be shared
Signature header	X-Chili-Signature, bare hex
Timestamp header	X-Chili-Timestamp, Unix seconds when the request was signed
Scheme	HMAC-SHA256
Signed content	<timestamp>.<raw body>
Secret	One per tenant. Requested from support@chilipiper.com, never shown in the app
Rotation	By email to support. The old secret stops working at once
Event field	type: Created, Updated or Deleted
Retries and timeout	Not documented
Source IPs	Not published

Common events

Action type	type	Fires when
For New Meeting	Created	A meeting is booked, from any source
For Meeting Update	Updated	A meeting is updated, for example reassigned or rescheduled
For Canceled Meeting	Deleted	A user or prospect cancels the meeting

The body is a flat meeting object with type last. Here is a trimmed version of Chili Piper's example, which it labels as example data:

{
  "meetingIdChili": "123e4567-e89b-12d3-a456-426614174000",
  "meetingTitle": "🔥 Demo Meeting: Support Call",
  "meetingStartTime": "2025-03-21T20:30:00Z",
  "meetingEndTime": "2025-03-21T20:45:00Z",
  "primaryGuestTimeZone": "America/New_York",
  "hostEmail": "host@example.com",
  "assigneeEmail": "support@example.com",
  "primaryGuestEmail": "demo@example.com",
  "primaryGuestDataFields": { "Email": "demo@example.com" },
  "bookerEmail": "booker@example.com",
  "workspaceName": "Customer Experience",
  "productFeatureType": "ConciergeRouter",
  "productFeatureName": "new-router-name",
  "meetingTypeName": "Support Session",
  "type": "Created"
}

Fields ending in IdChili are internal IDs that stay the same for a given meeting, person or asset, and Chili Piper support can use them to trace a meeting. productFeatureType says where the meeting came from, with values including ConciergeRouter, HandoffRouter, RoundRobinSchedulingLink, ChatPlaybook, DistroRouter and OwnershipSchedulingLink. primaryGuestDataFields holds the answers from the booking form, keyed by field name.

Setting up Chili Piper webhooks

1. In the Command Center, open Integrations and click Create Custom Webhook.
2. Choose the action type, paste your webhook URL and click Create.
3. Set the webhook's status to Enabled. It isn't active until you do.
4. Email support@chilipiper.com for your webhook signing secret, with the name of your instance (tenant) and the webhook you created. Store the secret server-side, for example as CHILI_PIPER_WEBHOOK_SECRET.
5. Repeat for each action type you need.

With Hookdeck. Chili Piper is a supported source type in Hookdeck. Chili Piper issues the signing secret on request: email Chili Piper support for your tenant's secret and paste it into the Hookdeck source. Use the Hookdeck source URL as the webhook URL in the Command Center. The source accepts POST only and checks X-Chili-Signature against <X-Chili-Timestamp>.<raw body>. A request that fails the check, including one sent before you've added the secret, still gets a 200 from Hookdeck, but Hookdeck marks it as failed verification and doesn't deliver it to your service.

Securing Chili Piper webhooks

Join the timestamp header, a literal ., and the raw body bytes. Compute an HMAC-SHA256 with the secret as a UTF-8 string and compare the hex digests in constant time.

const crypto = require('crypto');
const express = require('express');

function verifyChiliPiperSignature(rawBody, signature, timestamp, secret) {
  if (!signature || !timestamp || !secret) return false;
  if (!/^[0-9a-f]{64}$/i.test(signature)) return false; // validate before decoding

  const signed = Buffer.concat([Buffer.from(`${timestamp}.`, 'latin1'), rawBody]);
  const expected = crypto.createHmac('sha256', secret).update(signed).digest();
  const received = Buffer.from(signature, 'hex');
  return received.length === expected.length && crypto.timingSafeEqual(received, expected);
}

// Optional replay check, off by default (0). Hookdeck retries and replays resend the original timestamp.
const TOLERANCE_SECONDS = Number(process.env.CHILI_PIPER_WEBHOOK_TOLERANCE_SECONDS || 0);

const app = express();

app.post('/webhooks/chili-piper', express.raw({ type: '*/*' }), (req, res) => {
  const secret = process.env.CHILI_PIPER_WEBHOOK_SECRET;
  if (!secret) return res.sendStatus(500); // fail closed

  const timestamp = req.get('x-chili-timestamp');
  if (!verifyChiliPiperSignature(req.body, req.get('x-chili-signature'), timestamp, secret)) {
    return res.sendStatus(401);
  }
  if (TOLERANCE_SECONDS > 0 && Math.abs(Date.now() / 1000 - Number(timestamp)) > TOLERANCE_SECONDS) {
    return res.sendStatus(401);
  }

  const meeting = JSON.parse(req.body.toString('utf8'));
  // Route on meeting.type (Created, Updated, Deleted), then process asynchronously.
  res.sendStatus(200);
});

The same check in Python:

import hashlib
import hmac
import re

HEX_64 = re.compile(r"[0-9a-fA-F]{64}")


def verify_chili_piper_signature(raw_body: bytes, signature, timestamp, secret: str) -> bool:
    if not signature or not timestamp or not secret:
        return False
    if not HEX_64.fullmatch(signature):
        return False
    signed = timestamp.encode("latin-1") + b"." + raw_body
    expected = hmac.new(secret.encode("utf-8"), signed, hashlib.sha256).digest()
    return hmac.compare_digest(bytes.fromhex(signature), expected)

Chili Piper's own Node sample calls crypto.timingSafeEqual on the two strings without checking their lengths first, so a malformed header throws instead of returning false. Keep the length check shown above. Its samples also decode the body to a string before signing. That gives the same result for valid UTF-8, but signing the raw bytes is safer.

Chili Piper's docs suggest rejecting timestamps more than 5 minutes old. Hookdeck applies no timestamp tolerance, and its retries and replays resend the original headers, so a strict window rejects legitimate redeliveries. The sample leaves the check off unless you set a tolerance.

Make Chili Piper webhooks production-ready. Hookdeck Event Gateway verifies the X-Chili-Signature header, stores every booked, updated and canceled meeting, and retries delivery to your service on a schedule you control.

Chili Piper webhook limitations and pain points

The secret comes from support

The Problem: You can create and enable a webhook but have nothing to verify it with.

Why It Happens: Chili Piper doesn't display the signing secret in the Command Center. You request it by email, and its troubleshooting table lists an empty signature header as a symptom to check against the webhook's setup and whether you've received your secret.

Workarounds:

• Request the secret as soon as you create the first webhook, and don't route production traffic until verification passes.
• Ask support for a rotation the same way if the secret leaks.

How Hookdeck Can Help: Hookdeck's request log shows every delivery with its headers, including any that fail verification, so you can see straight away whether requests are arriving signed.

Rotation has no overlap

The Problem: Verification fails between a rotation and your next deploy.

Why It Happens: Chili Piper says rotating "immediately invalidates the previous one".

Workarounds:

• Schedule the rotation with support for a time when you can deploy the new secret straight away.
• Accept either secret in your verifier for the changeover, then remove the old one.

How Hookdeck Can Help: With Hookdeck in front, the secret lives on the source. Update it there once, and every service behind it keeps receiving verified events.

Undocumented delivery behaviour

The Problem: You can't tell from the docs whether a failed delivery comes back.

Why It Happens: The custom webhook article documents the payload and the signature, but no retry schedule, timeout or success rule.

Workarounds:

• Assume a failed delivery may be lost, and reconcile meetings from Chili Piper's reporting or your calendar data.
• Return 2xx quickly so a slow handler never causes a failure.

How Hookdeck Can Help: Hookdeck answers Chili Piper as soon as a request arrives and stores it, then delivers it to your service with automatic retries and lets you replay any event.

Best practices

Route on type, not only on the URL

Each webhook has one action type, so separate URLs would work. A single URL with a switch on type is simpler to run and keeps one verifier.

Deduplicate on the meeting and action

There's no event ID. Use meetingIdChili plus type as a key, and for Updated include the start time so that two different reschedules aren't merged. See our guide to webhook idempotency.

Keep personal data safe

The payload carries guest emails, names and form answers. Store only what you need, and keep the signing secret out of source control and client code, as Chili Piper advises.

Acknowledge fast and process asynchronously

Verify, store the meeting, return 200, and do CRM or warehouse writes afterwards. See why to process webhooks asynchronously.

Conclusion

Chili Piper signs each custom webhook with X-Chili-Signature, a hex HMAC-SHA256 of <X-Chili-Timestamp>.<raw body>, keyed with a tenant secret you request from support. Verify against the raw bytes with a length-checked constant-time comparison, route on type, and plan around undocumented retries by acknowledging quickly and keeping your own record of meetings.

Hookdeck Event Gateway sits in front of your receiver, checks every Chili Piper signature, and holds each meeting event until your service has processed it.

Get started with Hookdeck for free and handle Chili Piper webhooks reliably in minutes.