Eventually Ticketing
Sharing Your Events

What attendees see when they register

When an attendee clicks your event link, they land on a hosted public event page that shows your brand logo, event details, and either a registration flow or a read-only view depending on the event status.

The public event page

Standalone events use a hosted page at /e/:event_id, where the ID is the event's numeric event ID. To share a standalone event, copy its generated public event link. This page is the attendee-facing registration surface for a single event. Recurring series use a series page at /series/:id that lists all upcoming dates before attendees pick a session. The legacy /s/:id URL redirects to it.

The hosted page is automatically generated and does not require any Squarespace editing. It is the destination for direct event links shared in emails, social posts, or SMS campaigns.

Event Series pages

An Event Series has its own hosted page labeled "Event Series" that lists the sessions and dates the series ticket covers and states how many sessions the ticket covers. Buyers purchase the series ticket once and are seated in every listed session, instead of choosing and registering for a single date. For what buyers see during that purchase, see What attendees see when they buy an Event Series.

In the calendar widget, the Event Series badge marks the day chips and day rows. Once the first session has started, a card that still sells drop-ins shows "Series tickets closed" and "Drop-ins available" and links buyers to the next available session.

Event details on every view

Every event view uses the same details block, so attendees see the same information whether they open the event page, expand the event in your calendar, or start registering. The block shows the event date, a time when the event has one, and the venue when the event has a location: the venue is a link that opens a map in a new tab. The price row shows the remaining-ticket count, a Sold out status, or a Waitlist or Register status when a closed event offers another path. A locked or pre-sale event keeps its price but shows no remaining-ticket count. The Event time and Tickets left widget settings hide the time and the remaining-ticket count in every view. A team-wide Hide tickets remaining setting in Event Defaults hides the remaining-ticket count as well, on calendars, hosted event pages, and series pages. Sold out and waitlist statuses stay visible either way.

Read-only state for completed events

Once an event ends and its status becomes completed, the public event page stays accessible but switches to a read-only history view. The event title, description, date, and brand logo still appear, but ticketing and registration are disabled.

Instead of ticket quantities and a checkout button, completed events show a disabled Registration closed state. Attendees cannot register, RSVP, join a waitlist, or check out for a completed event. Only live, published events allow registration and purchase.

Search indexing for completed events

Completed events are excluded from search indexing. The page remains accessible as read-only history, but it carries a noindex tag and does not appear in the sitemap or generate structured data.

Published events with no ticket tiers

A live, published event can remain visible without accepting registration when it has no remaining ticket tiers. The event page and widget show the event details with no registration call to action, and public registration and checkout are unavailable until you add a tier again. This differs from a completed event: the page stays live as information only rather than switching to a read-only history view.

If you have uploaded a brand logo in Customize → Global Styles, it appears centered above the event card on the hosted public event page.

  • The logo is sourced from your site’s brand settings.

  • If an All Events page URL is set in Customize → Event defaults, the logo links to that URL so attendees can browse more of your events.

  • When the All Events page URL is blank, the logo falls back to linking to your site URL instead.

  • The logo is constrained to a maximum width of 400 pixels and scales down to fit narrower screens.

  • If no brand logo is set, the page omits the logo entirely and the event card sits at the top.

Ticket selection and registration

Attendees see available ticket types and quantities directly on the public event page. They select the tickets they want and proceed to the registration form.

For paid events, checkout uses the payment provider configured for the event: Squarespace or Stripe. When Squarespace is the provider, checkout flows through Squarespace Commerce using your site's connected payment processor. When a buyer starts from a standalone /e/ event link, a bridge page on your Squarespace site briefly transfers their ticket selection into the Squarespace cart before checkout. See Set up the checkout bridge page for standalone paid checkout. For free events, attendees complete a simple RSVP form without entering payment details.

If you set a More info button on your event, attendees on Eventually-registration events see the link as an outlined secondary button below the main registration button on the single-event view, and as a quiet inline link under the registration details in the registration popup. The link is informational and not an alternative way to register, and it is not shown on external-registration events. The link stays visible even when registration is sold out, closed, or locked for pre-sale.

Confirmation and next steps

After completing registration, attendees receive a confirmation with their ticket details and any add-to-calendar links. Paid registrations show Eventually's confirmation page after Squarespace payment processing. Free events display an RSVP confirmation inside the registration flow.

Visitors in the European Economic Area, the United Kingdom, Switzerland, and unknown countries see a cookie consent banner on the public event page, series page, and post-purchase confirmation pages. The banner lets them choose which cookie categories to accept before non-essential cookies load. Visitors elsewhere are not shown the banner by default, but can change their preferences in the app. For details, see Cookie consent and preference center.

Was this helpful?
Was this helpful?