One morning queue for every meeting waiting on your approval

Build me a booking triage desk for Cal.com that my sales ops person opens every morning to clear the queue of meetings still waiting on a human decision. The point of the app is to be one working screen that replaces jumping between Cal.com's separate Upcoming, Unconfirmed, Recurring, Past, and Cancelled tabs.

The main view is a single list of bookings that need confirmation. Load it with Cal.com's Get All Bookings, filtered to pending status and sorted by soonest start time, paging with the take and skip parameters. Each row shows the attendee name and email, the event type, when the call starts (with the time zone and a relative countdown like "in 6 hours"), and the answers they gave on the booking form.

Any pending booking starting in under 24 hours is pinned to the top of the list and styled in red, with a count of how many sit in that danger zone. Those are the ones that quietly rot into no-shows, so they should be impossible to miss when the page loads.

Beside each attendee, show CRM context from HubSpot so the reviewer knows who they are dealing with before deciding. Look the attendee email up with Search Contacts, and pull the full record with Get Contact, which accepts an email address through its idProperty parameter, for details like company, lifecycle stage, and owner. Summarize each one as a simple badge: existing customer, known contact, or total stranger. Do not fire these lookups for every row on page load. Batch them or load them lazily as rows come into view, because Cal.com allows 120 requests a minute and HubSpot has its own limits.

Every row has action buttons wired to the matching Cal.com operations: Confirm a Booking, Decline a Booking with a reason, Reschedule a Booking to a new time, Reassign a Booking to a different host, Cancel a Booking, and Add Guests to a Booking when someone needs a colleague pulled in. Decline, cancel, reschedule, and reassign should each open a small dialog to collect the reason, the new time, or the new host before anything is sent. Once an action succeeds, drop the row out of the pending queue and show a brief confirmation.

When a booking is reassigned, post a Slack message to the new host with the meeting details, attendee name, event type, start time, and the booking form answers, so they are not ambushed by a call they never saw. Use Slack's Send a Message. To reach the host directly, Open a Conversation with their user first to get the direct message channel, or let the operator pick a shared channel instead.

Adding guests is rate limited to 5 requests a minute, well below Cal.com's normal ceiling, so add guests one at a time from the dialog rather than looping over a bulk paste, and show progress in the UI instead of firing every request at once.

Two Cal.com API details to bake in. The v2 booking endpoints require a cal-api-version header set to 2026-02-25, and leaving it off surfaces as a confusing 404. Responses come wrapped as an envelope shaped like { "status": "success", "data": ... }, so unwrap data before rendering it.

Round it out with a manual refresh, filters for event type and host so several people can share the desk, and a clean empty state for when the queue is clear, since clearing it is the whole goal. Keep it readable at a glance. This is a surface someone works for ten minutes every morning, not a report they read.