Forms

EventPoint forms are configurable workflows that collect data and can create or update EventPoint resources. They are used when a fixed request body is not enough—for example, when questions vary by project, later pages depend on earlier answers, or submission must coordinate registration, scheduling, and commerce.

Advanced integration surface

Forms are not currently documented as public API endpoints, so this guide stays at the conceptual level. If you are interested in using EventPoint forms, ask your EventPoint contact for more information about available options, configuration, and integration support.

What forms can support

Depending on project configuration, a form can be used for:

• attendee registration, including registration groups, codes, tickets, and purchases;
• calls for content that create or update events;
• speaker, staffer, or other facilitator submissions;
• exhibitor, sponsor, company, membership, or representative workflows;
• session and event evaluations;
• appointment or resource scheduling; and
• general-purpose or anonymous data collection.

Forms can include multiple pages, conditional visibility and validation, prefilled values, file uploads, inventory or timeslot choices, summary steps, and commerce-related elements. The exact capabilities belong to the configured form, not to every form response.

Core concepts

Concept	Purpose
Form	Defines the workflow, settings, pages, and overall response behavior.
Assignment	Makes a form available in a particular context, such as an event, registration type, or another EventPoint object.
Element	Defines a question, content block, choice, validation rule, or specialized action on a page.
Conditional logic	Determines whether an element or path applies based on the current response.
Form response	Stores the submitter’s progress, answers, status, and links to created or updated resources.
Registration group	Connects one or more registrants and their form responses within the same registration workflow.

An assignment matters because the same form can behave differently depending on where it is used. Do not select a form by name alone; retain the assignment and object context supplied by EventPoint.

Typical response lifecycle

At a conceptual level, a forms experience follows this sequence:

1. Resolve the project, form assignment, and object context.
2. Load the form definition, its pages and elements, and any initial mapped values.
3. Render the current page using the supplied element settings and labels.
4. Prepare or validate the page submission so EventPoint can apply conditional logic, list data, mapping, and scheduling rules.
5. Save a draft or submit the page, retaining the returned form-response ID.
6. Repeat for later pages until the response is final.
7. Use the final result’s resource and commerce information instead of predicting those side effects in the client.

Let EventPoint evaluate the workflow

Do not duplicate conditional logic, price calculations, availability checks, or finalization rules in client code. Render the state returned by EventPoint and send answers back through the configured workflow so server-side rules remain the source of truth.

Forms and registration

A registration form can coordinate work that would otherwise span several API areas. It may start or resume a registration group, collect data for one or more registrants, validate a pass code, schedule events, add purchasable items, and finalize the response after payment or another required step.

Use direct registrant operations only when you need administrative record maintenance and do not need the configured attendee journey. Use the event registration lifecycle when you need registration rules without a complete forms experience. The Registration guide compares all three approaches and links the public lifecycle operations.

Interested in using forms?

Contact EventPoint before planning or implementing a forms integration. To help your EventPoint contact recommend the right approach, be ready to describe:

• the workflow and audience;
• whether submitters are authenticated people or anonymous visitors;
• which EventPoint resources the workflow should create or update;
• how drafts, abandoned responses, and resumed sessions should behave;
• whether payment, inventory, scheduling, or registration groups are involved;
• any reporting, data-retention, or external-system requirements; and
• the target project and expected launch timeline.

Form definitions can change without a client release. Build the interface from the returned labels, element types, required state, choices, and instructions; do not hard-code a project’s current page layout. Preserve accessible labels, error summaries, focus handling, and status announcements when rendering a custom experience.

Security and reliability

• Keep EventPoint credentials on a trusted server.
• Authorize every form, assignment, response, and related object in the current project context.
• Treat form-response IDs as opaque identifiers and retain them when saving or resuming a workflow.
• Check the current response before repeating a final submission or payment action.
• Avoid logging answers that contain personal, payment, or confidential data.

Start with About the API for the resource model and the Quickstart for identifier handling. Ask your EventPoint contact for current forms integration information rather than relying on undocumented endpoints.