Tripleseat

Tripleseat

Event and catering CRM for hospitality venues. Data is scoped to one customer account; most list tools work without extra ids.

First moves

1. List sites — discover site ids for webhook tools and see which venues exist in the account.
2. Leads / events / bookings — list with page (50 rows) or search with query and date filters.
3. Contacts / accounts / users — CRM and staff lookups; search by name with query.
4. Rooms / menus — venue spaces and catering menus for event planning.
5. Notes — pass parent_type (lead, event, booking, account, contact) and parent_id.

Hierarchy

Customer account → Sites → Locations → Rooms, events, bookings, guest room blocks.

Location ids appear on events and rooms; guest-room-block and PMS room-type tools require location_id.

Operational order

1. List sites when webhook tools need a site id or the account spans multiple venues.
2. Pull pipeline — recent leads or upcoming events (query + date filters on search).
3. Drill into a record by id, then fetch notes or event menu selections when needed.
4. Upserts — omit id to create, pass id to update; event and account payloads use inner field shapes (the upsert tool wraps event / account for the API).
5. Payment reports — need date or date-range filters; responses can be large.

Gotchas

• List endpoints return 50 rows per page — paginate with page; prefer search filters over wide list fan-out.
• Pass query or date filters to route to search endpoints; plain list calls ignore those filters.
• site_id is only required for webhook endpoint tools — pipeline and CRM lists do not need it.
• location_id comes from event or room records — required for guest-room blocks and PMS room types.
• Pass show_financial=true on events/bookings to include revenue and payment fields; omit it for pipeline summaries without money data.
• Upsert events and accounts expect inner field objects; leads, bookings, and contacts use flat payload shapes.
• Rate limit: 10 requests/second — batch thoughtfully across paginated reads.