Events SDK

For a complete task, start with the Events guide. This page covers the public Events SDK; see SDK basics for imports and peers.

Event ranges and all-day datesCopy Anchor Link

client.events.getRange() returns allDayStartDate and an exclusive allDayEndDateExclusive on each all-day event and occurrence. Show that date pair when isAllDay is true. The instant fields of an all-day row are local-midnight values kept for compatibility and indexing; do not convert them to the viewer's time zone to get display dates. Timed rows use startsAt and endsAt and return both date fields as null.

Discovery and unlisted linksCopy Anchor Link

client.events.getRange() lists published events with visibility=public. Its pages and totals exclude unlisted events, as do Publishable Key raw event and occurrence lists and counts. For an unlisted link, retain the event and occurrence IDs and read each with client.collections.from('events').findById(eventId) and client.collections.from('event-occurrences').findById(occurrenceId). Registration remains available when the event and occurrence meet the registration rules.

An id or slug filter on a raw list still follows listing visibility. To make an event discoverable, select visibility=public. Refresh cached lists and totals when the server's listing behavior changes.

Events AdmissionCopy Anchor Link

Use client.events.getAdmissionAvailability({ occurrence }) to show public paid admission choices for one occurrence.

import { createClient } from '@01.software/sdk'

type Client = ReturnType<typeof createClient>

export async function readAdmissionChoices(client: Client, occurrence: string) {
  const admission = await client.events.getAdmissionAvailability({ occurrence })
  if (admission.admissionTypes.length === 0) {
    return { kind: 'empty' as const, admission }
  }
  return { kind: 'choices' as const, admission }
}

The response includes the event and occurrence, the admission type, the productId and variantId for the existing Cart flow, the public price, and a remaining-capacity hint. Each admission type row includes the requested occurrenceId, also for admission types that cover the whole event. It does not include raw priceReference, product inventory, holds, Checkout or order records, payment sessions, provider event ids, or internal order amounts.

To buy, use the Ecommerce helpers: add the returned product and variant to a Cart with admissions: [{ eventId, occurrenceId, admissionTypeId }], then follow Cart → Checkout → PaymentSession. This helper is separate from the events.products data used by event commerce.

Cart line input and responses use admissions; there is no singular admission alias.

Pass market to select an active market handle or id, for example { occurrence, market: 'kr' }. Omit it to use the default market. Prices include that market's currency and id, using a fixed market price when configured or a calculated price otherwise. An unknown market returns 404 not_found. Create the Cart with the same market to keep displayed and purchase unit prices aligned; Checkout reads current prices again.

When a market resolves, the response includes only admission types whose product belongs to the same workspace and is assigned to that market. This filtering also applies when market is omitted and the default market is used. Missing products and empty market assignments are omitted. With no active market, base pricing keeps the existing unfiltered response.

Range and free registration methodsCopy Anchor Link

getRange returns events and occurrences with registration policy metadata. register submits a free registration, and guest lookup and cancellation use the returned guest credential. Cancellation revokes that credential, so do not redirect to a guest lookup with it. The Events guide covers the full availability, registration, and management flow, including the app-owned sign-in gate. Paid admission uses the separate Cart and Checkout flow in Events Admission.

My registrationsCopy Anchor Link

After customer sign-in, call client.events.listMyRegistrations({ page: 1, limit: 10 }). It needs the customer JWT and the matching Publishable Key with events enabled; a server key or operator session cannot act as the customer.

• page defaults to 1. limit defaults to 10, up to 100.
• The result has docs, totalDocs, limit, page, totalPages, hasNextPage, and hasPrevPage.
• Each registration has references, public title and time, registration and attendance status, quantity, and creation time. Missing or non-public details are null, while references and status remain. After personal data expires or is cleaned up, the shape stays the same.
• Guest credentials, attendee details and answers, audit fields, and locations are not included. All responses are no-store, and guest records with the same email are not linked.

createServerClient().events does not have this customer-only method. A server BFF creates a client per request with createClient({ publishableKey, customer: { persist: false, token } }), using the customer's JWT, and calls client.events.listMyRegistrations().

Next ActionsCopy Anchor Link

• SDK
• Webhooks

Registration email verificationCopy Anchor Link

For events with Verify registration email enabled, call client.events.requestRegistrationEmailVerification(input). When verificationRequired is true, collect the emailed 8-digit code and submit the same input to client.events.register with emailVerification: { requestId, code }. The code expires after 15 minutes and five attempts. No registration or seats are created until verification and a fresh capacity check succeed. Opt-out events keep immediate registration. Confirmations are limited to ten per tenant and recipient per rolling hour without canceling registrations; event-cancellation notices are exempt. Verification email has a separate three-per-hour cap, 60-second resend interval and ordinary email quota.

The request returns a processing receipt before delivery, in both Live and Sandbox. Complete verification with the emailed code before a seat is allocated. In Sandbox, only an active member of that exact workspace with a verified current email receives the code.

It uses the platform sender, a [Sandbox] subject and no Reply-To. Other recipients and ordinary event mail are captured; the public receipt stays the same. Sandbox shares its 100-per-month non-billable email ceiling.

Recipient limits suppress background delivery while returning the same receipt. The workspace request limit applies before processing and returns 429 when exhausted. Suppression is recorded in operator logs as recipient_verification_limit.