Platform · Integrations
Calendar, payments, comms, marketing, analytics and storage — connected with native integrations, webhooks and a typed API.
Google, Outlook and iCloud two-way sync per staff. Twilio for SMS and Resend and Postmark for email. Messaging channels beyond SMS and email (for example WhatsApp) can be added through the API and webhooks, so your own messaging stack can drive them.
Newsletter signups collect into a subscriber list you can export as CSV for any email platform. Meta Pixel, Google Tag Manager and Plausible for tracking. UTM-aware booking links.
Signed webhooks for every domain event. A typed REST API with examples for your own stack.
Google Meet, Zoom and Microsoft Teams links minted per booking, attached to the calendar event and the customer confirmation.
Booking events export with full context — push them into the CRM you already run via the signed webhooks and typed API.
Every webhook is signed and idempotent so you can build production flows on the automation stack you already run.
A 'native integration' is too often a glorified webhook with a logo. We hold ours to a higher bar. A native integration in QUE means we maintain the connection, we handle the auth refresh, we map the data with intent, and we own the support when it breaks. If a partner ships a breaking change, we fix it before you notice.
For each of the integrations we badge native, you get configuration in the dashboard (not a Zap), bidirectional sync where it makes sense (calendars, contacts), and clear status on whether the connection is healthy. Errors get human-readable explanations and one-click fixes.
We also publish what each integration does and doesn't do. No vague 'fully integrated' claims. You'll see the exact data flow before you flip the switch.
Webhooks are the contract between QUE and your stack. Signed with HMAC, delivered with at-least-once semantics, retried with exponential backoff, and observable in a delivery log you can replay from. Every domain event has a webhook: booking created, rescheduled, cancelled, paid, refunded, completed; customer created, updated, deleted; lead captured, converted; review submitted, approved.
Payloads are versioned. When we evolve the schema we ship a new version and let you upgrade on your timeline. Old versions are supported for at least twelve months.
For teams without a backend, the signed webhooks and the typed API expose the same events with the same payloads. Build a flow once and migrate it to your own stack later without rebuilding.
REST, typed, OpenAPI 3.1, with a generated SDK in TypeScript and Python on day one. The docs include runnable examples, copy-paste curl, and a Postman collection. Every endpoint is rate-limited fairly, paginated consistently, and errors with structured codes you can branch on.
Authentication is API key plus optional OAuth for end-user actions. Per-key scopes restrict what the integration can read or write. Every request is logged and surfaced in the integrations console.
We also ship a GraphQL endpoint on enterprise for teams that prefer query-shaped data, and a real-time channel over WebSocket for live updates.
Maintained
Native integrations
Each integration monitored and supported
Retry + replay
Webhook delivery
Signed events with a replay log in the dashboard
Versioned
API contract
Schema changes get a version, not a surprise
Documented
SDK surface
Typed TypeScript and Python SDKs
Use cases
Every confirmed booking keeps pipeline-ready context — event type, owner and tags — exportable for import into the CRM you already run.
Outcome · Booking context reaches your CRM with owner and tags instead of living in a spreadsheet.
Class reminder and membership renewal outreach stays attached to the booking record — export or sync it to the email platform you already run.
Outcome · Reminder and renewal outreach stays attached to booking context instead of living in a spreadsheet.
Each booking mints a unique Zoom link, attached to the calendar invite and the confirmation email.
Outcome · Each booking mints a unique Zoom link attached to the invite and the confirmation email.
Custom portal calls QUE's API for bookings, invoices and intake forms; uses QUE magic-link auth.
Outcome · The portal pulls bookings, invoices and intake from the API with magic-link auth.
Every booking and refund streams to an internal Kafka topic for the finance team's dashboards.
Outcome · Every booking and refund streams to the finance team's dashboards as it happens.
Use the typed SDK to render booking flows inside a partner's product, branded as theirs.
Outcome · The typed SDK renders booking flows inside a partner's product, branded as theirs.
Capabilities
Calendar, Meet, Drive and Maps.
Checkout, Connect, refunds and webhooks.
SMS, MMS and email through configured providers.
Resend, Postmark and SendGrid.
Signed, retried, observable.
Every event, signed, documented, idempotent.
Push events, sync contacts, attach notes via webhooks.
Same webhooks, your own runtime.
How we compare
| What you need | Legacy tools | QUE |
|---|---|---|
| Calendar sync | One-way, 60s polling | Two-way, webhook-driven where supported |
| Webhooks | Fire-and-forget | Signed, retried, replayable, versioned |
| Native CRM | Zap with manual mapping | Dashboard config, bidirectional contacts |
| Conferencing | Manual link entry | Auto-mint Meet, Zoom or Teams per booking |
| SDK quality | Untyped, hand-rolled docs | OpenAPI 3.1, generated TS + Python SDK |
| Self-host friendly | Copy-paste scripts | Webhooks, typed API, your own runtime |
Yes. Use the webhooks and typed API to build whatever you need, or hire our Solutions team to ship it for you. Custom integrations on enterprise come with SLA-backed support.
Start with QUE
Configuration that adapts to the booking flow your team already runs.