Overview

Events let an account publish something people can attend — a workshop, a fundraiser, a webinar — and track who's coming. An event can offer one or more ticket types, and attendance is tracked with a registration that links a constituent to the event.

Events

An event has a title, location, summary, a rich-text description, a rich-text after-sale/confirmation message, a start and optional end time, an optional capacity, and an optional image. Publishing state is controlled independently of the time fields, so an event can be drafted well before it goes live.

starts_at is required; ends_at, if set, must be after starts_at.
capacity, if set, must be greater than zero.
Built-in scopes: published, upcoming (starts_at in the future), past.

Tickets

Each event can offer multiple ticket types via EventTicket:

Ticket type: free, paid, or donation.
Cost is stored in cents; paid and donation tickets require payment.
Quantity available and an availability window (available_at / available_until) control when and how many of a ticket can be claimed.
Visible toggles whether a ticket is shown publicly — use this for comp or staff-only tickets.

Registrations

A Registration is the attendee role edge: it belongs to a constituent and an event, and optionally to a specific ticket. Registrations carry:

Status: pending, confirmed, canceled, or attended.
Quantity (must be greater than zero — e.g. one constituent registering for a table of four).
registered_at, set automatically on creation if not provided.

A registration's ticket, if present, must belong to the same event as the registration itself.

Managing events over MCP

Events and tickets are available as MCP tools, so they can be managed conversationally the same way collection entries and templates can:

events_list / events_get / events_save / events_delete
event_tickets_save / event_tickets_delete

Registrations themselves are not exposed over MCP — like the rest of the constituent CRM, attendee data is managed through the staff CRM UI or the constituent's own portal rather than an AI-accessible tool, since it's personal data tied to a real person's activity history.

Public event signup

The starter site's events page renders a form_for form (handle event_signup) inside each event card for collecting interest: name, email, which event, and a guest count. The form has constituent ingestion enabled, mapping name and email onto a constituent so the same person is recognized on repeat signups, while the raw submission (including which event and guest count) is stored as a regular collection entry.

This form-based signup is separate from the formal Registration role edge described above. A constituent's registrations are shown read-only on their CRM profile; a self-service ticket checkout that writes Registration rows directly is not yet built. See Form For Tag for rendering forms and Constituents & CRM for how ingestion maps fields onto a constituent.

Displaying events in Liquid

Use the events collection like any other content when listing upcoming events on a page:

{% for event in events limit: 6 %}
  <h3>{{ event.title }}</h3>
  <p>{{ event.location }}</p>
  <p>{{ event.starts_at | date: "%B %-e, %Y" }}</p>
{% endfor %}