Platform, Integrations & Extensibility

Customers are requesting an API endpoint for deleting or removing users from CP to simplify automated workflows. This feature is currently under review for potential future implementation.

When building a Zap with Chili Piper as the trigger, Zapier only surfaces the first meeting ever scheduled in the instance as test data. Admins can't test against different scenarios, such as a lead vs. a contact, different Meeting Types, or varied form submissions, without live data happening to match. Update the Chili Piper Zapier integration to allow users to choose from multiple recent meetings when selecting test data during Zap setup, rather than being locked to a single historical record. Zap configurations that can only be tested against one static record are brittle. Admins building scenario-specific automations either ship untested logic or wait for the right live event to occur, both of which increase the risk of silent failures in production.

Workato is a widely used enterprise automation platform, but Chili Piper doesn't have a native Workato integration. Teams using Workato for enterprise-grade automation have to build custom API workarounds instead of using a supported connector. Build a native Workato connector for Chili Piper with feature parity to the existing Zapier integration, so Workato users can trigger and respond to Chili Piper events without custom development. Enterprise customers increasingly standardize on Workato over Zapier for its governance, permissions, and IT control features. The absence of a native connector creates friction at the deal stage for enterprise prospects and limits automation options for existing customers on Workato.

The workspace name is included in the Zapier new meeting payload when a meeting is booked via a router, but is absent when a meeting is booked directly via a Meeting Type link. This inconsistency means teams building automations on top of Zapier or webhooks cannot reliably use workspace as a grouping or routing condition in their flows, since the field only exists for a subset of bookings. Chili Piper should include the workspace name in the meeting payload for all booking methods, including Meeting Type links, personal scheduling links, and any other entry point, not only router-booked meetings. Workspace is a fundamental organizational attribute of every meeting in Chili Piper. Omitting it from non-router payloads forces automation builders to handle inconsistent data structures and prevents workspace-based logic from working reliably across all booking flows.

Static scheduling links can't be scoped to a specific campaign or capped by use count. Teams sharing links in outbound sequences have no way to track which campaign drove a booking, and nothing prevents a prospect from reusing a link outside the intended window. A POST endpoint should allow developers to programmatically generate unique booking URLs with a configurable max_event_count and a specified owner or Meeting Type. Once the limit is reached, the link expires. This is a direct Calendly parity gap. Teams currently work around it with UTM parameters, which are unreliable, or avoid dynamic link generation entirely.

When a custom webhook fails due to an issue on the receiving end, such as an endpoint timeout or HTTP 500, Chili Piper provides no log of the failure and no way to resend the event. Admins discover failures only through downstream gaps, such as missing records or broken automation flows, and have no recovery path except manual workarounds or API intervention. For high-volume users, this means missed bookings and lost data with no built-in remedy. Chili Piper should provide a webhook delivery log that surfaces failed events with timestamps, payload details, and error codes, and allow admins to manually resend individual or bulk failed events directly from the admin dashboard. Resent events should include unique event IDs to support idempotency and prevent duplicate processing. Webhook delivery failures are a standard operational risk for any integration-heavy platform. Without visibility into failures and a way to recover from them, admins have no reliable way to ensure data integrity between Chili Piper and external systems. A delivery log with resend capability is a baseline reliability feature expected by enterprise teams running critical automations on top of webhook data.

Chili Piper's webhook for new meetings fires for all Concierge meeting data with no way to scope it to specific routers. Teams that only need data from certain Concierges are forced to add a filtering layer in their own automation platform, such as Power Automate or Zapier, to exclude irrelevant events before they can act on them. This adds unnecessary processing overhead on the customer side and increases data transfer volume on both ends. Chili Piper should allow admins to configure webhook subscriptions to include or exclude specific Concierges or routers, so only the relevant meeting events are sent to the endpoint. Webhook consumers shouldn't need to build their own filtering logic to compensate for missing configuration options in the source system. Scoped webhooks reduce noise, lower processing overhead for both parties, and make integrations simpler to build and maintain, particularly for teams running complex automation workflows against high-volume meeting data.