Checkin

<usecase>Count add-ons across many events at once - e.g. how many course cards, dinners or t-shirts were ordered over all events in a quarter. Add-ons are optional extras bought alongside a ticket or an order. Every event has its own add-ons, so one product sold on 100 events is 100 add-ons: this tool adds them up by name.</usecase><instructions>addOnName matches part of an add-on's name or of one of its options, ignoring case ('card' finds 'Plastic card' and 'Card - documented training'); omit it to list every add-on. The narrative names what matched: check it before reporting a total. fromDate and toDate (YYYY-MM-DD, inclusive, at most a year apart) pick events by start date, or add-ons by purchase date with dateBasis='purchase'. groupBy='add_on' (default) gives one row per add-on name, option and currency, summed over events; groupBy='event' one row per event and add-on, with the addOnId event-sales(eventId, focus='addons', addOnId) takes. totalQuantity is the units buyers hold: waitlisted and cancelled units are left out, and so is anything free: a free question or choice is an answer, which find-attendees(eventId, include='answerBreakdown') counts per event when it is asked per ticket. Money, per currency and never added across currencies: revenueAfterDiscountsExcludingVat and revenueAfterDiscountsIncludingVat are what buyers were charged, revenueIncludingVat the list price including VAT before discounts. Covers every organization this connection is authorized for unless organizationIds narrows it; event rows carry organizationId and organizationName.</instructions>

compare-add-ons

<usecase>Compare multiple events or view revenue across all events. Two modes: 'compare' (default) for side-by-side metrics of 2-10 specific events, 'revenue_overview' for organization-wide revenue breakdown by event.</usecase><instructions>For 'compare' mode: provide eventIds (list of 2-10 event IDs). Returns per-event: orders, tickets sold, check-in rate, no-show rate, ticket revenue, average order total. For 'revenue_overview' mode: returns per-event ticket revenue across events with pagination, one row per event and currency, and totals split by currency - amounts in different currencies are never added together. Money: ticketRevenueAfterDiscountsExcludingVat and ticketRevenueAfterDiscountsIncludingVat (both modes) are what buyers were charged for their tickets, each after its own discount - the figures for actual ticket income. ticketRevenueIncludingVat (both modes) and addOnRevenueIncludingVat (revenue_overview only) are list prices including VAT, before discounts. All leave out waitlisted and cancelled tickets and add-ons, and booking fees. For revenue per ticket type or add-on, or up to a date, use event-sales(eventId). avgOrderTotalIncludingVat (compare only; avgOrderTotalExcludingVat without VAT) is the average of what buyers are charged for a whole order - tickets, add-ons and fees, after discounts; a cancelled order counts at the fee the organizer kept. Each amount sits next to its 'currency'. This connection may cover several organizations (a parent and its subunits, or every organization a user holds organization-wide access in); most cover only one. Both modes work across all authorized organizations - 'compare' can mix events from different organizations, and 'revenue_overview' aggregates across all authorized organizations by default. Every event is tagged with organizationId and organizationName. Pass organizationIds to restrict revenue_overview to specific organizations. Use find-events() first to discover event IDs.</instructions>

compare-events

<usecase>Accommodation an event sells beside its tickets - hotel rooms, cabins, campsites: room types per location, rooms booked and left, guest places still to be filled, room revenue, and occupancy night by night. Use it for questions about rooms, beds, overnight stays or hotel blocks on any event, whatever its eventType.</usecase><instructions>A room type is a kind of room sold at a location (e.g. 'Double room' at 'Hotel Bristol'). A booked room has one place per guest, and each place is named (a ticket holder, or a guest the organizer named), not filled in (held by a ticket the buyer has not filled in yet) or open (nobody yet). Buyers on unspecified orders book rooms by number of guests and fill the places in later, by namesDueAt when the organizer set one. roomCountMode 'whole_stay': roomsForSale counts rooms for the whole stay window. 'per_night': every night has its own count - add include='nights' for them, and for rooms occupied, arriving and leaving each night. Cancelled rooms are left out; cancelledButStillChargedExcludingVat is what buyers still pay for cancelled rooms and add-ons. Room revenue is room prices after discounts, add-ons not included; include='addOns' lists the accommodation add-ons (breakfast, parking...) with their sales. Order totals in find-orders, event-finances and event-dashboard include accommodation; ticket revenue in event-sales does not. Use find-room-bookings(eventId) for who sleeps in which room.</instructions>

event-accommodation

<usecase>Check-in monitoring and attendance analysis for an event. Auto-detects whether the event is live (shows real-time dashboard) or past (shows no-show/late arrival analysis). Override with the 'mode' parameter. Check-in = attendees having their ticket/badge verified at a physical entrance gate.</usecase><instructions>'live' mode: shows check-in rate, per-ticket-type breakdown, per-checkpoint scan counts (countsAsEventArrival marks the checkpoints where an inward scan checks the attendee in to the event - an outward scan at an IN_OUT checkpoint does not; scanCount counts every passage, uniqueTicketsScanned each ticket once), check-in timeline (counts per time bucket), and recent individual check-ins - those are absent for an organization that has switched personal data off, and meta.piiNote says so. 'post_event' mode: shows no-show count/rate, late arrivals (checked in after event start), and per-ticket-type no-show breakdown. Mode is auto-detected from event dates if not specified.</instructions>

event-check-in

<usecase>Get a dashboard for one event. Returns headline metrics (orders, attendees, check-in rate, revenue, capacity) plus full event configuration in 'eventDetails': event type (EVENT/TICKETS/COURSE/HYBRID/ONLINE/ELEARNING/BOOKING), location, registration window, enabled payment methods (card, Vipps (Norwegian mobile payment), Swish (Swedish mobile payment), invoice, pay-at-door), seat map settings, ticket delivery (email/SMS), invoice settings, and when the event was created and by which user (createdAt, createdByName, createdByEmail; on older events the contact person stands in for the creator, and an event created through the API has none).</usecase><instructions>Use 'include' to add sections: 'velocity' (run rate, projected sell-out), 'waitlist' (per-ticket-type waitlist counts), 'post_event' (no-shows, top tickets/add-ons/coupons, hourly check-in curve, payment collection). Add-ons are paid extras bought with tickets (e.g., parking, meals, t-shirts); anything free is an answer. Multiple values can be comma-separated. Without 'include', returns the core summary which is fast and token-efficient. Money: ticketRevenueIncludingVat and addOnRevenueIncludingVat are list prices including VAT, before discounts, of the tickets and add-on units buyers hold - waitlisted and cancelled ones left out, booking fees not included - and totalRevenueIncludingVat is their sum; event-sales(eventId) gives them after discounts. In 'post_event', orderTotalIncludingVat (orderTotalExcludingVat without VAT) is what buyers were charged for their non-cancelled orders: the whole order after discounts, rooms and fees included - the figure for net revenue. totalDiscountsExcludingVat is every discount given: on tickets, on add-on lines and on whole orders (each listed beside it). paymentCollectionRate is the share of that charge already paid; outstandingBalanceIncludingVat is what buyers still owe, cancelled orders included, since a cancelled order can keep a fee. Every amount is in the event's 'currency'.</instructions>

event-dashboard

<usecase>Financial health overview for an event: payment status breakdown, aging buckets for outstanding amounts, and optionally the orders still awaiting payment.</usecase><instructions>Returns aggregates only: payment status counts, aging buckets and totals. Use find-orders(eventId, unpaidOnly=true, includeCancelled=true) for the individual orders behind these numbers. Per payment status, orderTotalIncludingVat is what buyers are charged for the whole order (tickets, add-ons, accommodation, booking fees, after discounts) and orderTotalExcludingVat the same without VAT; outstandingBalanceIncludingVat is what buyers still owe and refundsOwedToBuyersIncludingVat what is owed back to buyers who paid more than their order now costs. outstandingBalanceIncludingVat adds up to the aging buckets' total. Cancelled orders are included: a cancelled order is rewritten to the fee the organizer keeps, which can still be owed. Every amount is in the event's 'currency'. Add include='awaiting_payment' to also count registrations still expected to pay (statuses: pending, waiting_payment, waiting, reminder, requires_action) and the amount they still owe. These are live registrations, not lost sales.</instructions>

event-finances

<usecase>Detailed sales analysis for a single event: revenue per ticket type, sales over time, add-on sales and discounts. Add-ons are optional extra products buyers pay for alongside tickets (e.g., parking, meals, t-shirts); a free question or choice is an answer: find-attendees(eventId, include='answerBreakdown') counts those asked per ticket, and find-orders(eventId, include='fieldCatalog') shows those asked per order, order by order.</usecase><instructions>Set 'focus': 'overview' (default) - tickets sold and revenue per ticket type, plus add-on and whole-order totals. 'time_series' - ticket sales by day, week or month with cumulative totals; ticketTypeId narrows it to one ticket type. 'addons' - units, revenue and attachment rate per add-on; addOnId narrows it to one add-on, and groupBy adds its sales by day, week or month. 'discounts' - every discount given, excluding VAT, with coupon usage. fromDate/toDate (YYYY-MM-DD) cut overview, time_series and addons by when each ticket or add-on was bought - e.g. to compare sales up to the same date in two years. Money: fields named AfterDiscounts are what buyers were charged, the figures for actual revenue - each ticket after its own discount, each add-on line after its discount - ExcludingVat and IncludingVat. A discount on a whole order belongs to no ticket type or add-on, so it is reported on its own (orderDiscountsExcludingVat) and taken off only in totalRevenueAfterDiscounts. Revenue fields without AfterDiscounts are list prices including VAT, before discounts: list value, not income. Waitlisted and cancelled tickets and add-ons are left out and booking fees are not included. Every amount is in the event's 'currency'.</instructions>

event-sales

<usecase>Search and list attendees for a specific event. Supports filtering by name/email, ticket type, and check-in status. Optionally include anonymized answer counts for the event's custom fields (dietary, accessibility, etc.).</usecase><instructions>An attendee holds a ticket: cancelled tickets and those on the waitlist are left out, as every attendee count in these tools leaves them out, unless includeCancelled or includeWaitlisted is true - then each one says so (isCancelled, isWaitlisted). Money per ticket, in the order's currency: ticketPriceAfterDiscountExcludingVat and ticketPriceAfterDiscountIncludingVat are what the buyer was charged for the ticket after its discount (its add-ons not included), ticketDiscountExcludingVat and couponCode the discount given, and ticketPriceIncludingVat the ticket type's list price before any discount. PII is masked by default (initials + masked email). Ask the user before passing format='detailed', and never use it on your own initiative. An organization can switch personal data off entirely; when it has, identifying fields are absent and meta.piiNote says so. Counts, amounts and statuses are unaffected. Add include='answerBreakdown' for an anonymized count of how attendees answered each custom field (grouped by field and answer; no names - good for catering/logistics. Predefined choice options are always counted; free-text values are personal data and are listed only with format='detailed'). To read individual attendees' answers - the registration form's own questions such as company, job title and date of birth, and the event's custom fields (additionals) - first call with include='fieldCatalog' to discover what the event has, then pass attendeeFields=[...] (field names, keys or ids) to attach only those answers to each attendee - avoid requesting fields you don't need. Answer values count as personal data and are shown only with format='detailed'. If find-contacts is listed, use find-contacts(search) instead for cross-event contact history.</instructions>

find-attendees

<usecase>Look up contacts by name, email, or phone. Returns contact details and their registration history across all events (events attended, ticket list-price total, recent events).</usecase><instructions>Provide either a search term (min 2 characters) or a contactId for exact lookup. Returns up to 10 contacts by default. PII is masked by default. Ask the user before passing format='detailed', and never use it on your own initiative. An organization can switch personal data off entirely; when it has, identifying fields are absent and meta.piiNote says so. Counts, amounts and statuses are unaffected. Use contactId for exact lookup if you already have a contact ID. totals.ticketListPriceTotalIncludingVat adds up the list prices, including VAT and before discounts, of the tickets where the contact is the attendee - waitlisted ones included, cancelled ones left out. It is not what the contact paid: a ticket someone else bought for them counts, the tickets they bought for others do not, and fees and add-ons are not in it. It is in totals.currency; a contact with tickets in more than one currency gets ticketListPriceTotalsByCurrency instead. Use find-attendees(eventId, search) instead to search within a specific event. This connection may cover several organizations (a parent and its subunits, or every organization a user holds organization-wide access in); most cover only one. By default contacts from ALL authorized organizations are searched, each tagged with organizationId and organizationName. Pass organizationIds to restrict to specific organizations - call list-organizations() first to see which ones are available. An organization that has switched personal data off is left out of the search; meta.organizationsLeftOut names each one.</instructions>

find-contacts

<usecase>Find and list events. This is the starting point for most workflows - use it to discover event IDs before drilling into details with other tools.</usecase><instructions>Filters: period (upcoming/live/past/all), search by name, include unpublished drafts. Results are sorted by start date (newest first by default). Each result includes eventId, eventName, dates, registration window, location, event type (EVENT = standard/default event type (not booking, and not classified as online or hybrid), TICKETS = anonymous tickets, COURSE = multi-session, HYBRID = physical+online, ONLINE = digital-only, ELEARNING = self-paced, BOOKING = accommodation/resource reservation), organizer, and order count. Each result also includes a 'visibility' object showing where the event is listed (showInEventCalendar, showInEmbeddedCalendar, showOnLandingPage, showInGlobalSearch, showInCheckinSearch, and isHiddenEverywhere when none are enabled) plus isCancelled/cancelledAt. Use these to distinguish events hidden from the public calendar (e.g. duplicate events for extra rooms/halls) from publicly listed ones. createdAt is when the event was created, and createdByName and createdByEmail the user who created it. On older events Checkin recorded no creator, and they are the event's contact person instead, usually but not always the creator. An event created through the API has neither. This connection may cover several organizations (a parent and its subunits, or every organization a user holds organization-wide access in); most cover only one. By default events from ALL authorized organizations are returned, each tagged with organizationId and organizationName. Pass organizationIds to restrict to specific organizations - call list-organizations() first to see which ones are available.</instructions>

find-events