Checkin

<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: ticketRevenueIncludingVat (both modes) and addOnRevenueIncludingVat (revenue_overview only) 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. 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); 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>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), booking/accommodation config, 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 optional extras purchased alongside tickets (e.g., parking, meals, t-shirts). 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. In 'post_event', orderTotalIncludingVat (orderTotalExcludingVat without VAT) is what buyers were charged for their non-cancelled orders: the whole order after discounts, 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, 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. Supports four focus areas: revenue overview (default), time-series trends, add-on performance, and discount/coupon analysis. Add-ons are optional extra products buyers can purchase alongside tickets (e.g., parking, meals, t-shirts).</usecase><instructions>Set 'focus' to choose the analysis type: 'overview' (default) - revenue breakdown by ticket type + add-on totals. 'time_series' - ticket sales grouped by day/week/month with cumulative totals. 'addons' - per-add-on quantity, revenue, and attachment rate. 'discounts' - every discount given, excluding VAT: totalDiscountsExcludingVat is ticketDiscountsExcludingVat (on each ticket, with coupon usage and manual discounts), addOnDiscountsExcludingVat (on add-on lines) and orderDiscountsExcludingVat (discount lines on a whole order), and discountPercentOfListPrice sets it against the list price excluding VAT of the tickets and add-on units held. Date filters (fromDate/toDate in YYYY-MM-DD) apply to overview and time_series. Money: revenue figures (ticketRevenueIncludingVat, addOnRevenueIncludingVat, totalRevenueIncludingVat) 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. Discounts are stored excluding VAT, so discount figures say ExcludingVat and are compared with the list price excluding VAT. Every amount is in the event's 'currency'. For what buyers were actually charged use event-dashboard(eventId, include='post_event').</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 includeWaitlisted is true - then each waitlisted one says so (isWaitlisted). ticketPriceIncludingVat is the ticket type's list price including VAT, before any discount, in the order's currency. 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 and job title, 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' (like full names/emails). Use find-contacts(search) instead if you need 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); 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.</instructions>

find-contacts

<usecase>Find and list events for your organization. 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); 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

<usecase>Search and list orders for a specific event. Use this to find individual orders by contact name, email, invoice reference, or payment status.</usecase><instructions>Filters: search (name/email/invoice reference), paymentStatus (done, pending, waiting_payment), unpaidOnly (outstanding balance > 0), includeCancelled. orderTotalIncludingVat is what the buyer is charged and orderTotalExcludingVat the same without VAT - the whole order, tickets, add-ons, fees and all, after discounts; outstandingBalanceIncludingVat is what of the charge is still unpaid (below 0: the buyer is owed money back), so an order nobody has paid shows the two equal. A cancelled order is rewritten to the fee the organizer keeps. Each order carries its currency. orderType is who the buyer bought for: SINGLE, FAMILY, GROUP, CORPORATE, RESERVATION (seats for others to fill in) or OTHER. ticketCount is the tickets the buyer holds - cancelled and waitlisted ones left out. PII is masked by default: contact details are masked and the invoice reference (a free-text 'reference message' written by the buyer) is withheld. 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. To read order-level answers - the buyer's registration questions such as organization number and reference, and the event's order-level custom fields (additionals) - first call with include='fieldCatalog' to discover what the event has, then pass orderFields=[...] (field names, keys or ids) to attach only those answers to each order - avoid requesting fields you don't need. Answer values count as personal data and are shown only with format='detailed'. (Per-attendee fields are in find-attendees.) Use event-finances(eventId) instead for aggregate payment status overview.</instructions>

find-orders

<usecase>List the organizations this connection can access. A single connection may cover one organization (the common case) or a parent organization together with its subunits. Call this first when a request is about a specific organization, or when you need to know whether more than one organization is in scope.</usecase><instructions>Takes no parameters - it always returns exactly the organizations the connection is authorized for. Each entry includes organizationId, organizationName, organizationType (organization/company/charity/subunit), isPrimaryConsentOrganization (the organization consent was granted to), parentOrganizationId/Name, and directSubunitCount. Pass an organizationId from these results to other tools via their organizationIds parameter to scope a query to specific organizations. Organization structures are at most one level deep: an organization is either standalone, a parent (has subunits), or a subunit (has a parent) - never both a parent and a subunit.</instructions>

list-organizations