Event Architect API: parse, apply, and manage sessions
Full reference for the four Event Architect endpoints: session management, prompt parsing, plan application, and session deletion with TypeScript examples.
Use this file to discover all available pages before exploring further.
The Event Architect API lets you build the parse → review → apply workflow programmatically. All four endpoints are scoped to a meeting (event) and require a bearer token obtained through the standard JTE Panel login flow.
A session is the server-side state that holds the most recently parsed plan for a user and event combination.
Scope: keyed on (userId, meetingId). One user can have independent sessions across multiple events.
Tab sharing: the same user opening the same event in multiple tabs shares a single session and a single current plan.
Sliding TTL: the session expires after 120 minutes of inactivity. Any read or write operation resets the timer and updates lastActivityAt and expiresAt.
Auto-creation: sending a prompt via POST /messages creates a session automatically if none exists.
The natural-language instruction describing the changes to make. Maximum length is determined by the AI model’s context window; keep prompts under 25,000 characters for best results.
POST /api/event-architect/meetings/9f9e2cc9-390a-4dd0-a56a-c5f5ffddf6ff/session/messagesAuthorization: Bearer <token>Content-Type: application/json{ "prompt": "Set capacity to 500, add Early Bird ticket for 99 PLN, and add form fields company and job title."}
Applies the currently stored plan to the event data in the database. The plan must have been created by a prior call to POST /session/messages.
POST /api/event-architect/meetings/{meetingId}/session/apply
This endpoint has no request body.
Applying a plan with redoFromScratch: true replaces the existing event configuration. Tickets that have already been purchased are preserved, but all other settings are overwritten.
The key TypeScript interfaces for the Event Architect API are:
export interface EventArchitectParseRequest { prompt: string}export interface EventArchitectParseResponse { plan: EventArchitectPlan session: EventArchitectSessionResponse}export interface EventArchitectSessionResponse { meetingId: string // GUID currentPlan?: EventArchitectPlan | null originalUserRequest?: string | null createdAt: string // ISO 8601 lastActivityAt: string // ISO 8601 expiresAt: string // ISO 8601}export interface EventArchitectApplyResult { redoFromScratch: boolean capacityMessage: string ticketsCreated: number ticketsUpdated: number ticketsDeleted: number ticketsPreservedUsed: number webhookApplied: boolean webhookEventCount: number landingPageMessage: string persistedFormFieldsCount?: number | null}
The frontend does not send currentStateJson. The server builds current event state from the database. Send only { "prompt": "..." } in the request body.