| Input | How to get it |
|---|---|
| Visitor token | STEP 1 |
Event id, slug, registration.initialType (RSVP or TICKETING), dates, location, categories, calendar links | STEP 2 |
Ticket definition ids and prices (ticketed events) | STEP 3 |
| Guest first name, last name, email (RSVP) — the form is built in, do not invent extra fields | Ask the visitor |
reservationId (tickets) | STEP 5 |
registration.initialType === "RSVP".fields: ["CATEGORIES"], filter client-side on categories.categories[].name.status: "YES"; "NO" only when registration.rsvp.responseType === "YES_AND_NO".calendarUrls.google / calendarUrls.ics.dateAndTimeSettings.formatted.dateAndTime is already a human string in the event's timezone (e.g. October 24, 2026, 9:00 AM – 1:30 PM GMT+3) — quote it as is.dateAndTimeSettings.startDate is UTC; use it only for sorting and for "next month" arithmetic in the business timezone (GetBusinessDetails → timeZone).status to UPCOMING/STARTED.GenerateVisitorToken once; reuse it.
POST https://www.wixapis.com/events/v3/events/query
Filtering by slug in the query returned nothing on this site — fetch the upcoming list and match slug/title client-side.
POST https://www.wixapis.com/events/v1/checkout/available-tickets/query — the visitor-public read. ticket-definitions endpoints are management-only and 403 the visitor.
Remaining stock is not exposed to visitors — answer "on sale" / "sale ended", never a count. Empty definitions with saleStatus missing means sold out or not yet on sale.
POST https://www.wixapis.com/events/v2/rsvps — body must be wrapped in rsvp.
→ { "rsvp": { "id": "…", "status": "YES", "email": "dana@example.com", … } }. Tell the visitor a confirmation email is on its way. Use "status": "NO" only when the event's rsvp.responseType is YES_AND_NO.
POST https://www.wixapis.com/events/v1/ticket-reservations — body must be wrapped in ticketReservation.
Success → { "id": "<reservationId>", "status": "PENDING", "expires": "…" } (held ~20 minutes). On a site with no payment provider the same call returns 403 { "message": "No payment method configured" } — that is a site-owner setting, not a bug; tell the visitor tickets aren't on sale online yet and offer the contact details from GetBusinessDetails.
POST https://www.wixapis.com/_api/redirects-api/v1/redirect-session
→ redirectSession.fullUrl. Never hand-build /event-details/<slug>/ticket-form (404 on headless sites) and never call the legacy POST /events/v1/checkout to pay inline.
ExecuteWixAPI masks the real error as "Visitor token rejected (HTTP 403)"Both the 400 ticketReservation must not be empty and the 403 No payment method configured came back as a token error from the sandbox. Re-run the single call with CallWixSiteAPI to read the real message before deciding what to tell the visitor.
400 rsvp.firstName must not be empty / ticketReservation must not be emptyYou sent a flat body. Wrap: { "rsvp": { … } } and { "ticketReservation": { "tickets": [ … ] } }.
POST /events/v1/tickets/available/query → 404The visitor read is POST /events/v1/checkout/available-tickets/query. Docs search "available tickets" lists it as Query Available Tickets.
403 No payment method configured on ticket reservationExpected on sites without a payment provider / premium plan. Do not retry with another token; explain and point to the business contact.
slug returns events: []Query the upcoming list and match client-side.
/events/v1/categoriesManagement-only. Request fields: ["CATEGORIES"] on the event query and read categories.categories[].name.
| Constant | Value |
|---|---|
| Wix Events app id | 140603ad-af8d-84a5-2c80-a0f60cb47351 |
| Events query fields | ["DETAILS", "TEXTS", "REGISTRATION", "URLS", "CATEGORIES"] |
Last updated: 17 September 2026