About the API

EventPoint models an event as something that happens—usually at a time and location, and often with people involved.

This shared model supports conferences, sessions, meetings, trips, appointments, and other workflows without a separate API structure for each one. An event type defines the behavior available to an event.

Example using conference and sessions

A traditional conference API often exposes a fixed hierarchy: a program has sessions, and sessions have speakers. EventPoint represents each level as an event:

• the conference is a top-level event;
• each session is a child event whose parentId identifies the conference; and
• each event’s eventTypeId identifies the event type that classifies it.

The event’s type settings can control capabilities and defaults such as scheduling, notifications, timeslots, structured locations, enrollment, facilitators, metadata, and presentation. An individual event can also carry its own timing, location, hierarchy, organizer, categories, and metadata.

Think in capabilities

Start by asking what the event needs to do, not which traditional conference label it resembles. The event type supplies the capabilities; the event holds the instance data.

Event data model

The diagram shows the relationships most useful to API consumers. It is a conceptual view of the public model rather than a database schema.

erDiagram
    accTitle: EventPoint event data model
    accDescr: A project defines event types and contains events. Events can contain child events, have an optional organizer, assign facilitators with facilitator types, and record attendee enrollment for a person.

    PROJECT ||--o{ EVENT_TYPE : defines
    PROJECT ||--o{ EVENT : contains
    EVENT_TYPE o|--o{ EVENT : classifies
    EVENT o|--o{ EVENT : "is parent of"
    ORGANIZER o|--o{ EVENT : organizes
    EVENT }o--o{ FACILITATOR : assigns
    FACILITATOR }o--o{ FACILITATOR_TYPE : "serves as"
    EVENT ||--o{ EVENT_ATTENDEE : records
    PERSON o|--o{ EVENT_ATTENDEE : identifies

Projects

The project is the primary container. It contains event types, events, registrants, and related configuration such as locations, timeslots, categories, facilitator types, and metadata fields.

Most requests require a projectId.

Events and hierarchy

Every conference, session, meeting, or activity is an event. Events can be nested: parentId points to the immediate parent, while topLevelId identifies the root of the hierarchy. A hierarchy can represent a conference and its sessions, a trip and its activities, or another project-defined structure.

Organizers, facilitators, and facilitator types

An event can have an organizer and can assign multiple facilitators. EventPoint does not require a dedicated speaker entity. Instead, facilitator types describe the role a facilitator performs for an event.

For example, one facilitator can be assigned to a session with the roles Speaker and Content owner. The same model can assign a Staffer to a staffing event or a Driver to a bus-trip event.

Attendees

Event enrollment creates an event-attendee record. It connects participation to an event and can associate that participation with a person. The record also holds workflow state such as enrollment, attendance, preference, and waitlist information.

For a conference schedule, a person can be an attendee of the conference event and separately enroll as an attendee in selected session events.

An attendee can also schedule a meeting with other attendees. The person who creates that meeting becomes the organizer of the new event.

Registration and forms

A registrant represents a person’s registration for an event under a configured registration type. Registration can be maintained directly, processed through the event registration lifecycle, or coordinated by a form. See Registration to choose the appropriate approach.

Forms add project-configured questions, conditional paths, mapping, scheduling, and commerce to resource workflows. They can create or update registrants, events, facilitators, companies, evaluations, and general responses. See Forms for the conceptual model and access expectations.

Useful endpoints

Goal	Operation
Resolve a project code	GET /api/projects/get-for-code
List a project’s event types	GET /api/projects/{projectid}/event-types
Query events and child events	POST /api/events/query
Get an event’s organizer	GET /api/events/{eventid}/organizer
List facilitators by role	GET /api/events/{eventid}/facilitators-for-type
List event attendees	GET /api/events/{eventid}/attendees

Use the Quickstart to resolve codes into the GUIDs these operations expect. The generated API reference is the source of truth for supported fields, parameters, and response schemas. Review API conventions before implementing write operations.