@wix/agent-skills 1.32.0 → 1.33.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (30) hide show
  1. package/README.md +21 -0
  2. package/package.json +2 -2
  3. package/skills/wix-app/references/DASHBOARD_PAGE.md +1 -1
  4. package/skills/wix-app/references/EDITOR_REACT_COMPONENT.md +40 -41
  5. package/skills/wix-app/references/editor-react-component/ANIMATED-COMPONENTS.md +11 -6
  6. package/skills/wix-app/references/editor-react-component/DESIGN-STATES.md +2 -3
  7. package/skills/wix-app/references/editor-react-component/DISABLED-INVALID.md +31 -0
  8. package/skills/wix-app/references/editor-react-component/MANIFEST-ERRORS.md +14 -1
  9. package/skills/wix-app/references/editor-react-component/PARTS.md +32 -3
  10. package/skills/wix-app/references/editor-react-component/SSR.md +6 -3
  11. package/skills/wix-headless-kit/install/pins.json +1 -1
  12. package/skills/wix-manage/SKILL.md +25 -7
  13. package/skills/wix-manage/references/automations/actions.md +11 -11
  14. package/skills/wix-manage/references/automations/activation-status.md +6 -9
  15. package/skills/wix-manage/references/automations/api-catalog.md +48 -32
  16. package/skills/wix-manage/references/automations/automation-model.md +97 -22
  17. package/skills/wix-manage/references/automations/bracket-expressions.md +7 -7
  18. package/skills/wix-manage/references/automations/build-and-manage-automations.md +140 -309
  19. package/skills/wix-manage/references/automations/conditions.md +187 -0
  20. package/skills/wix-manage/references/automations/schemas-and-scheduling.md +191 -0
  21. package/skills/wix-manage/references/automations/special-actions.md +210 -0
  22. package/skills/wix-manage/references/automations/triggers.md +47 -10
  23. package/skills/wix-manage/references/automations/validation-and-verification.md +320 -0
  24. package/skills/wix-manage/references/custom-apps/use-app-tools.md +124 -0
  25. package/skills/wix-manage/references/events/create-wix-event.md +136 -73
  26. package/skills/wix-manage/references/events/manage-event-guests.md +366 -0
  27. package/skills/wix-manage/references/events/manage-event-tickets.md +293 -0
  28. package/skills/wix-manage/references/events/manage-wix-events.md +313 -55
  29. package/skills/wix-manage/references/stores/update-product-with-options.md +58 -2
  30. package/skills/wix-manage/references/custom-apps/use-app-skills-and-app-tools.md +0 -208
@@ -0,0 +1,366 @@
1
+ ---
2
+ name: "Manage Event Guests"
3
+ description: "Manages the people registered for a Wix event — RSVPs on RSVP events, and orders, tickets and ticket holders on ticketed events: listing and counting guests, adding or removing a guest, changing an RSVP, checking guests in, and marking orders paid. Use when the user asks who is coming or how many registered, or wants to add, remove or check in a guest. Notes what the API can't do, such as refunds and resending emails."
4
+ ---
5
+
6
+ # Manage Event Guests
7
+
8
+ ## Goal
9
+ Read and change who is registered for an event. How guests are stored depends on the event's
10
+ `registration.initialType`:
11
+
12
+ | Event type | Guests are | API |
13
+ | --- | --- | --- |
14
+ | `RSVP` | RSVPs — one per person who responded, with up to 10 additional guests each | RSVP V2, `https://www.wixapis.com/events/v2/rsvps` |
15
+ | `TICKETING` | Orders (the buyer) containing tickets (one per attendee) | Orders and Tickets, `https://www.wixapis.com/events/v1/...` |
16
+ | either | A combined read-only guest view | Event Guests, `https://www.wixapis.com/events/v2/guests/query` |
17
+
18
+ Find the event and its type first — this exact body:
19
+
20
+ ```bash
21
+ curl -X POST 'https://www.wixapis.com/events/v3/events/query' \
22
+ -H 'Content-Type: application/json' \
23
+ -H 'Authorization: <AUTH>' \
24
+ --data-binary '{
25
+ "query": {
26
+ "filter": { "title": { "$eq": "<EVENT_TITLE>" } },
27
+ "paging": { "limit": 100 }
28
+ },
29
+ "fields": ["REGISTRATION"]
30
+ }'
31
+ ```
32
+
33
+ - `paging` is a sibling of `filter` inside `query`; nested inside `filter` it fails `400`.
34
+ - Send it as is: no extra filter fields and no `sort` — a nested `registration` filter or a `sort`
35
+ inside `filter` fails `400`. Read the type and dates from the result instead.
36
+ - Don't send `includeDrafts` — `true` needs a draft-events permission and fails `403`.
37
+ - The id is `events[].id`, the type `events[].registration.initialType`. If several events match,
38
+ pick by date or ask ([Manage Wix Events](https://dev.wix.com/docs/api-reference/business-solutions/events/skills/manage-events#find-an-event)).
39
+
40
+ Registration rules (closing registration, guest limit, waitlist)
41
+ are event settings under `event.registration`, changed with `PATCH https://www.wixapis.com/events/v3/events/<EVENT_ID>` ([Manage Wix Events](https://dev.wix.com/docs/api-reference/business-solutions/events/skills/manage-events)).
42
+
43
+ **Find the event first, then work only on its branch.** Its `registration.initialType` decides
44
+ everything below: `RSVP` uses only the RSVP calls, `TICKETING` only the ticketing ones. Look up
45
+ schemas only for the calls of that branch — never prepare both.
46
+
47
+ **Reference pages for the calls below** — the full contract of each; use these rather than
48
+ searching for them:
49
+
50
+ | Call | Reference |
51
+ | --- | --- |
52
+ | Find the event | [Query Events](https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/events-v3/query-events), [Get Event](https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/events-v3/get-event) |
53
+ | Guests, any event | [Query Event Guests](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/event-guests/query-event-guests) |
54
+ | RSVP events | [Search RSVPs](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/rsvp-v2/search-rsvps), [Get RSVP](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/rsvp-v2/get-rsvp), [Create RSVP](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/rsvp-v2/create-rsvp), [Update RSVP](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/rsvp-v2/update-rsvp), [Delete RSVP](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/rsvp-v2/delete-rsvp) |
55
+ | Ticketed events | [Create Ticket Reservation](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/ticketing/ticket-reservations/create-ticket-reservation), [Checkout](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/ticketing/orders/checkout), [List Orders](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/ticketing/orders/list-orders), [List Tickets](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/ticketing/tickets/list-tickets) |
56
+ | Ticketed events: ticket types | [Query Ticket Definitions](https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/ticket-definitions-v3/query-ticket-definitions), [Create Ticket Definition](https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/ticket-definitions-v3/create-ticket-definition) |
57
+
58
+ Follow only the branch for the event's type: an RSVP event never needs the ticketing calls.
59
+
60
+ ## Prerequisite — the Wix Events app
61
+
62
+ Every call here returns `428 WIX_EVENTS_APP_NOT_INSTALLED` on a site without the Wix Events app.
63
+ Install it with appDefId `140603ad-af8d-84a5-2c80-a0f60cb47351`:
64
+ `POST https://www.wixapis.com/apps-installer-service/v1/app-instance/install` with
65
+ `{"tenant":{"tenantType":"SITE","id":"<SITE_ID>"},"appInstance":{"appDefId":"140603ad-af8d-84a5-2c80-a0f60cb47351"}}` —
66
+ `appDefId` nests under `appInstance`. See [Install Wix Apps](https://dev.wix.com/docs/api-reference/business-management/app-installation/skills/install-wix-apps).
67
+
68
+ ## List an event's guests
69
+
70
+ **Any event — the combined view.** `POST https://www.wixapis.com/events/v2/guests/query`:
71
+
72
+ ```bash
73
+ curl -X POST 'https://www.wixapis.com/events/v2/guests/query' \
74
+ -H 'Content-Type: application/json' \
75
+ -H 'Authorization: <AUTH>' \
76
+ --data-binary '{
77
+ "query": {
78
+ "filter": { "eventId": "<EVENT_ID>", "attendanceStatus": "ATTENDING" },
79
+ "cursorPaging": { "limit": 100 }
80
+ },
81
+ "fields": ["GUEST_DETAILS", "GUEST_TOTAL"]
82
+ }'
83
+ ```
84
+
85
+ Each of `guests[]` has `guestType` (`RSVP`, `BUYER` or `TICKET_HOLDER`), `attendanceStatus`
86
+ (`ATTENDING`, `NOT_ATTENDING`, `IN_WAITLIST`), `rsvpId` or `orderNumber`/`ticketNumber`,
87
+ `contactId`, `totalGuests` (only with `GUEST_TOTAL`), and — with `GUEST_DETAILS` —
88
+ `guestDetails.{firstName, lastName, email, phone, formResponse, checkedIn}`. Without
89
+ `GUEST_DETAILS` the names and emails are not returned; without `GUEST_TOTAL` there is no
90
+ `totalGuests` to count with. Page with `pagingMetadata.cursors.next`.
91
+
92
+ **Count people, not records.** On a ticketed event a buyer appears once as `BUYER` and once per
93
+ ticket as `TICKET_HOLDER`, so one order of 2 tickets is 3 guest records. To count attendees, filter
94
+ `"guestType": "TICKET_HOLDER"` (ticketed) or sum `totalGuests` over `RSVP` guests with
95
+ `ATTENDING` (RSVP), and say which you counted.
96
+
97
+ Attendance mapping: an RSVP `YES` is `ATTENDING`, `WAITLIST` is `IN_WAITLIST`, `NO` is
98
+ `NOT_ATTENDING`; an order that is `PAID`, `FREE` or `OFFLINE_PENDING` is `ATTENDING`, and `PENDING`
99
+ is `NOT_ATTENDING`.
100
+
101
+ **Confirm a change from its response, not a search.** The RSVP search lags a few seconds behind
102
+ writes; to read back a guest you just added or changed, use the create or update response or the
103
+ single `GET`, or wait a few seconds before searching.
104
+
105
+ **RSVP events — with form answers.** `POST https://www.wixapis.com/events/v2/rsvps/search`:
106
+
107
+ ```json
108
+ {
109
+ "search": {
110
+ "filter": { "eventId": "<EVENT_ID>", "status": "YES" },
111
+ "search": { "expression": "jane", "fields": ["firstName", "lastName", "email"] },
112
+ "cursorPaging": { "limit": 100 }
113
+ },
114
+ "fields": ["DETAILS", "CONTACT_DETAILS", "FORM"]
115
+ }
116
+ ```
117
+
118
+ `rsvps[]` carry `id`, `revision`, `status`, `firstName`, `lastName`, `email` (with
119
+ `CONTACT_DETAILS`), `form.inputValues` (with `FORM`), `totalGuests`, `guestList.guests[]` (each
120
+ with an integer `guestId` and `checkInDetails`), and `fullyCheckedIn`. Drop `search.search` to list
121
+ everyone. Totals per event: `GET https://www.wixapis.com/events/v2/rsvps/summaries?eventId=<EVENT_ID>`
122
+ returns `yesGuestCount`, `noGuestCount`, `waitlistGuestCount`, `totalRsvpCount`.
123
+
124
+ **Ticketed events — orders and tickets.**
125
+ - Orders: `GET https://www.wixapis.com/events/v1/orders?eventId=<EVENT_ID>&fieldset=DETAILS&fieldset=TICKETS&limit=100`
126
+ — `orders[]` with `orderNumber`, `fullName`, `email`, `status`, `ticketsQuantity`, `totalPrice`,
127
+ `tickets[]`. Add `&fieldset=FORM` for the buyer's form answers, `&status=OFFLINE_PENDING` to list
128
+ unpaid pay-at-the-door orders, `&searchPhrase=<name or email>` to find one.
129
+ - Tickets: `GET https://www.wixapis.com/events/v1/tickets?eventId=<EVENT_ID>&fieldset=GUEST_DETAILS&fieldset=TICKET_DETAILS&limit=100`
130
+ — `tickets[]` with `ticketNumber`, `orderNumber`, `ticketDefinitionId`, `name`, `guestFullName`,
131
+ `checkIn`, `orderStatus`. Add `&fieldset=GUEST_FORM` for each ticket holder's answers (filled only
132
+ when the event collects one form per ticket); otherwise the answers are on the order's `FORM`.
133
+ - Sales totals: `GET https://www.wixapis.com/events/v1/orders/summary?eventId=<EVENT_ID>`.
134
+
135
+ These two are `GET` list calls with repeated query parameters — there is no `POST .../query` for
136
+ orders or tickets. Exclude archived ones with `&tag=NON_ARCHIVED` (orders) or
137
+ `&state=ORDER_ACTIVE&state=TICKET_ACTIVE` (tickets). Both page by offset: the response carries
138
+ `total`, `offset` and `limit`; repeat the call with `&offset=<offset + limit>` until you have
139
+ `total` items, and don't report a list or count as complete before then.
140
+
141
+ ## Add a guest manually
142
+
143
+ A request that names both the guest and the event is the user's explicit instruction to add
144
+ them — proceed without asking again. Ask first when the event or the guest is ambiguous, for a
145
+ mandatory form answer you don't have, or which ticket to use when it isn't clear. Send the usual
146
+ confirmation email unless the user said not to.
147
+
148
+ Take the branch from the event's `registration.initialType` (from the find query) and read only
149
+ that branch: an RSVP event never needs ticket definitions, reservations or checkout.
150
+
151
+ **RSVP event.** The two calls below are complete for adding a guest — no schema lookup is needed.
152
+ 1. `GET https://www.wixapis.com/events/v3/events/<EVENT_ID>?fields=FORM` — read
153
+ `event.form.controls[].inputs[]` for each input's `name`, `mandatory` flag and `options`.
154
+ 2. `POST https://www.wixapis.com/events/v2/rsvps`:
155
+
156
+ ```bash
157
+ curl -X POST 'https://www.wixapis.com/events/v2/rsvps' \
158
+ -H 'Content-Type: application/json' \
159
+ -H 'Authorization: <AUTH>' \
160
+ --data-binary '{
161
+ "rsvp": {
162
+ "eventId": "<EVENT_ID>",
163
+ "firstName": "Jane",
164
+ "lastName": "Doe",
165
+ "email": "jane@example.com",
166
+ "status": "YES",
167
+ "form": {
168
+ "inputValues": [
169
+ { "inputName": "firstName", "value": "Jane" },
170
+ { "inputName": "lastName", "value": "Doe" },
171
+ { "inputName": "email", "value": "jane@example.com" }
172
+ ]
173
+ },
174
+ "disableNotifications": false
175
+ }
176
+ }'
177
+ ```
178
+
179
+ - On a form with only the built-in name and email, `form` is optional — the top-level `firstName`,
180
+ `lastName` and `email` are enough. Once the form has extra questions, `form.inputValues` must
181
+ use the input names from step 1 and include every mandatory one — otherwise
182
+ `400 INVALID_FORM_RESPONSE` (for example `input custom [''] must not be empty`). Ask the user for
183
+ mandatory answers you don't have, or send `"ignoreFormValidation": true` in `options` if they
184
+ want the guest added without them.
185
+ - **Duplicates are not reliably rejected** — a second RSVP with the same email can be created
186
+ without an error. Before adding, search the event's RSVPs for that email (the `rsvps/search` call
187
+ above, with `search.expression`). Only if that finds one, change it instead of adding another
188
+ (Get and Update RSVP below); otherwise go straight to the create.
189
+ - For a guest bringing others, add `{ "inputName": "additionalGuests", "value": "2" }` and
190
+ `{ "inputName": "guestNames", "values": ["Pat Lee", "Sam Lee"] }` to `inputValues`, and
191
+ `"additionalGuestDetails": { "guestCount": 2, "guestNames": ["Pat Lee", "Sam Lee"] }` — only when
192
+ the form has an additional-guests control. The RSVP then counts as 3 people: `totalGuests` 3
193
+ and one `guestList.guests[]` entry each (ids 1, 2, 3; ask for them with `"fields": ["DETAILS"]`),
194
+ and the event's `yesGuestCount` goes up by 3 while `totalRsvpCount` goes up by 1. A count above the
195
+ control's `maxGuests` fails `400 INVALID_FORM_RESPONSE`; a count without names fails
196
+ `400 ADDITIONAL_GUESTS_MUST_HAVE_NAMES`.
197
+ - **Full event.** A "yes" for a full event fails `428 RSVPS_CLOSED` — whether or not it has a
198
+ waitlist. Offer the user the waitlist first: send `"status": "WAITLIST"` (works when
199
+ `waitlistEnabled` is on). If they want the guest to take a place anyway, retry once with **both**
200
+ `"options": { "ignoreLimits": true, "ignoreResponseStatus": true }` — `ignoreLimits` alone still
201
+ fails `RSVPS_CLOSED`, and `ignoreResponseStatus` alone fails `GUEST_LIMIT_EXCEEDED` ("guest
202
+ limit … exceeded").
203
+ - **Closed or not-yet-open registration** fails `428 RSVPS_CLOSED` / `RSVPS_NOT_STARTED`; if the
204
+ user wants the guest added anyway, retry once with `"options": { "ignoreResponseStatus": true }`.
205
+ In both cases tell the user the limit or closed registration was overridden. Don't send these
206
+ options up front.
207
+ - `disableNotifications: true` turns notifications off for this RSVP. The API records the flag but
208
+ doesn't report whether an email went out, so tell the user notifications were turned off rather
209
+ than that no email was sent.
210
+ - `428 MEMBER_ALREADY_REGISTERED` / `MEMBER_EMAIL_ALREADY_REGISTERED` — an RSVP for this member or
211
+ email already exists; find it with the search above and change it instead.
212
+ - `400 UNEXPECTED_RSVP_STATUS` — the event only accepts "yes" (`rsvp.responseType` `YES_ONLY`, the
213
+ default); to record a "no", switch it with `PATCH https://www.wixapis.com/events/v3/events/<EVENT_ID>` and
214
+ `{ "event": { "registration": { "rsvp": { "responseType": "YES_AND_NO" } } } }`.
215
+ - `428 INVALID_EVENT_TYPE` — the event is ticketed; use the ticket flow below.
216
+
217
+ **Ticketed event.** A manual guest is a reservation followed by a checkout:
218
+
219
+ 1. Pick the ticket definition ([Manage Event Tickets](https://dev.wix.com/docs/api-reference/business-solutions/events/skills/manage-event-tickets#list-an-events-tickets)).
220
+ For complimentary guests ("free", "comp", "on the guest list") use a **free** ticket
221
+ (`fixedPrice.value` `"0"`, `feeType` `NO_FEE`). If the event has none, offer to create a hidden
222
+ free ticket for them; never put comp guests on a paid ticket.
223
+ 2. `POST https://www.wixapis.com/events/v1/ticket-reservations`:
224
+
225
+ ```json
226
+ {
227
+ "ticketReservation": {
228
+ "tickets": [ { "ticketDefinitionId": "<TICKET_DEFINITION_ID>", "quantity": 2 } ],
229
+ "additionalReservationSettings": { "enableHiddenTicketReservation": true }
230
+ }
231
+ }
232
+ ```
233
+
234
+ - `additionalReservationSettings` goes **inside** `ticketReservation`. Send it only when the
235
+ ticket is hidden; a hidden ticket without it — or with it at the body's top level — fails
236
+ `428 TICKET_DEFINITION_HIDDEN`.
237
+ - **If the event's first public ticket was created just now, wait for registration to open
238
+ before reserving.** It opens a second or two after the first ticket goes on sale: read
239
+ `GET https://www.wixapis.com/events/v3/events/<EVENT_ID>?fields=REGISTRATION` until
240
+ `registration.status` is `OPEN_TICKETS`, waiting about a second between reads (up to five
241
+ reads), then reserve. Doing this in the same script as the ticket creates saves a retry.
242
+ - `428 REGISTRATION_CLOSED` on a hidden ticket: registration hasn't opened yet (see above) or
243
+ the event has no visible ticket on sale. Wait and retry once; if it persists, tell the user the
244
+ event needs a public ticket first (or reopen registration: `PATCH https://www.wixapis.com/events/v3/events/<EVENT_ID>` with
245
+ `{ "event": { "registration": { "registrationPaused": false } } }`).
246
+ - `"disableTicketLimitValidation": true` (same object) lets the reservation exceed the ticket's
247
+ remaining quantity and can oversell the event — send it only after the user agrees to go over
248
+ the limit.
249
+ - Read `ticketReservation.id`. The reservation expires at `expirationDate` — check out straight
250
+ away.
251
+ 3. `POST https://www.wixapis.com/events/v1/checkout`, with one `guests[]` entry per ticket, each
252
+ form built from the event's form as for RSVPs:
253
+
254
+ ```json
255
+ {
256
+ "eventId": "<EVENT_ID>",
257
+ "reservationId": "<RESERVATION_ID>",
258
+ "buyer": { "firstName": "Jane", "lastName": "Doe", "email": "jane@example.com" },
259
+ "guests": [
260
+ { "form": { "inputValues": [ { "inputName": "firstName", "value": "Jane" }, { "inputName": "lastName", "value": "Doe" }, { "inputName": "email", "value": "jane@example.com" } ] } },
261
+ { "form": { "inputValues": [ { "inputName": "firstName", "value": "Pat" }, { "inputName": "lastName", "value": "Lee" }, { "inputName": "email", "value": "pat@example.com" } ] } }
262
+ ],
263
+ "options": { "silent": false }
264
+ }
265
+ ```
266
+
267
+ The response's `order` has the `orderNumber` and `status` — `FREE` for free tickets.
268
+
269
+ **Who holds each ticket.** Unless the event collects one form per ticket, every ticket is held
270
+ by the buyer: the extra `guests[]` entries are not stored, and the guest query shows the buyer's
271
+ name and email on each ticket. With `registration.tickets.guestsAssignedSeparately: true` (set it
272
+ with `PATCH https://www.wixapis.com/events/v3/events/<EVENT_ID>` and `{ "event": { "registration": { "tickets": { "guestsAssignedSeparately": true } } } }`,
273
+ with the user's agreement) each `guests[]` entry becomes that ticket's holder, under their own name — send one
274
+ entry per ticket.
275
+
276
+ `checkout.options` decide how a paid ticket is settled — set them from what the user said, never
277
+ by default:
278
+ - `"payInPerson": true` — the guest pays at the door; the order is `OFFLINE_PENDING`, and its total
279
+ includes the service fee when the ticket's `feeType` is `FEE_ADDED_AT_CHECKOUT`.
280
+ - `"markAsPaid": true` — **only** when the user says the guest already paid outside the site. It
281
+ records the order as `PAID`; on a comp guest it reports revenue that was never received.
282
+ - `"silent": true` — no confirmation email.
283
+ - `"ignoreFormValidation": true` — skip mandatory form answers the user doesn't have.
284
+
285
+ If checkout fails, delete the reservation so its tickets are released:
286
+ `DELETE https://www.wixapis.com/events/v1/ticket-reservations/<RESERVATION_ID>`.
287
+
288
+ ## Change an RSVP
289
+
290
+ `PATCH https://www.wixapis.com/events/v2/rsvps/{rsvp.id}` with the RSVP's current `revision`:
291
+
292
+ ```json
293
+ {
294
+ "rsvp": { "id": "<RSVP_ID>", "revision": "<REVISION>", "eventId": "<EVENT_ID>", "status": "YES" }
295
+ }
296
+ ```
297
+
298
+ - Move someone off the waitlist: `status` from `WAITLIST` to `YES`. If that fails because the event
299
+ is full, tell the user; only when they agree to go over the limit, retry once with
300
+ `"options": { "ignoreLimits": true, "ignoreResponseStatus": true }`.
301
+ - Mark someone not attending: `status` `NO`.
302
+ - Several at once (up to 100): `PATCH https://www.wixapis.com/events/v2/bulk/rsvps/update` with
303
+ `{ "rsvps": [ { "rsvp": { "id": "<RSVP_ID>", "revision": "<REVISION>", "status": "NO" } } ], "returnEntity": true }`,
304
+ then check `results[].itemMetadata.success` and report failures.
305
+ - **Take the `revision` from a fresh read** (`GET https://www.wixapis.com/events/v2/rsvps/<RSVP_ID>`),
306
+ never from the create response. On `INVALID_REVISION` (single or bulk item), read the RSVP again
307
+ and retry once.
308
+
309
+ ## Remove a guest
310
+
311
+ Confirm first. Deleting an RSVP can't be undone; archiving an order or ticket hides it from the
312
+ guest list and can be reversed by sending the same call with `"archived": false`.
313
+ - RSVP: `DELETE https://www.wixapis.com/events/v2/rsvps/<RSVP_ID>`.
314
+ - Several RSVPs: `POST https://www.wixapis.com/events/v2/bulk/rsvps/delete-by-filter` with
315
+ `{ "filter": { "eventId": "<EVENT_ID>", "id": { "$in": ["<RSVP_ID>"] } } }`. Always include
316
+ `eventId`: the filter otherwise spans every event, and an empty filter is refused
317
+ (`400 EMPTY_FILTER`). It runs asynchronously and returns a `jobId`: wait a few seconds, then
318
+ confirm with an RSVP search — not with the event's `summaries` counts, which update later.
319
+ - Ticketed: archive the order — `PATCH https://www.wixapis.com/events/v1/events/<EVENT_ID>/orders`
320
+ with `{ "orderNumber": ["<ORDER_NUMBER>"], "archived": true, "fields": { "paths": ["archived"] } }`
321
+ — or a single ticket, `PATCH https://www.wixapis.com/events/v1/tickets` with
322
+ `{ "eventId": "<EVENT_ID>", "ticketNumber": ["<TICKET_NUMBER>"], "archived": true }`. Archiving
323
+ does not refund the payment.
324
+
325
+ ## Check guests in
326
+
327
+ - RSVP: `POST https://www.wixapis.com/events/v2/rsvps/<RSVP_ID>/check-in` with
328
+ `{ "guestIds": [1] }` — integer `guestList.guests[].guestId` values read from that RSVP (search
329
+ with `DETAILS`), matched to the person by `fullName`; not GUIDs — a GUID fails
330
+ `400 Not a numeric value`. For a guest you just added, create the RSVP with
331
+ `"fields": ["DETAILS"]`: its response already carries `guestList.guests[].guestId` (the RSVP's own
332
+ guest is `1`), so no extra read is needed. Undo: same body to `.../cancel-check-in`.
333
+ - Ticketed: `POST https://www.wixapis.com/events/v1/tickets/check-in` with
334
+ `{ "eventId": "<EVENT_ID>", "ticketNumber": ["<TICKET_NUMBER>"] }` (up to 100). Undo:
335
+ `DELETE https://www.wixapis.com/events/v1/tickets/check-in?eventId=<EVENT_ID>&ticketNumber=<TICKET_NUMBER>`.
336
+
337
+ `428 GUEST_ALREADY_CHECKED_IN` / `GUEST_NOT_CHECKED_IN` mean there is nothing to change. Count
338
+ checked-in guests with the guest query filtered `"guestDetails.checkedIn": true`.
339
+
340
+ ## Mark an order as paid
341
+
342
+ `POST https://www.wixapis.com/events/v1/events/<EVENT_ID>/orders/confirm` with
343
+ `{ "orderNumber": ["<ORDER_NUMBER>"] }` moves `OFFLINE_PENDING`, `PENDING` or `INITIATED` orders to
344
+ `PAID` and emails the tickets to the buyer. `PAID` and `FREE` orders are unchanged. Confirm with
345
+ the user first. The order number is the code shown on the order, such as `FM9X-EHKF-ZO`. The
346
+ response is `orders[]` — read `status` `PAID` there; a separate order read immediately afterwards
347
+ can come back without a status.
348
+
349
+ ## Not available through the API
350
+
351
+ Say so, and point the user to the event's Guests or Orders page in the dashboard:
352
+ - **Refunds.** No Events API refunds an order; refunds are issued through the payment provider
353
+ from the order in the dashboard. Archiving or cancelling does not refund.
354
+ - **Resending a confirmation or ticket email.** There is no resend call.
355
+ - **Export to CSV.** Build the list from the queries above and give it to the user instead.
356
+ - **Moving a ticket to another date or occurrence, or upgrading it.** The workaround is a new
357
+ manual guest on the other event and archiving the original order — confirm both steps.
358
+ - **Importing a guest list.** Add guests one by one with the calls above.
359
+
360
+ ## Related APIs
361
+ - **RSVP V2**: [REST](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/rsvp-v2) — [Create Rsvp](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/rsvp-v2/create-rsvp)
362
+ - **Ticketing (orders, tickets, reservations)**: [REST](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/ticketing)
363
+ - **Event Guests**: [REST](https://dev.wix.com/docs/api-reference/business-solutions/events/registration/event-guests)
364
+ - [Manage Wix Events](https://dev.wix.com/docs/api-reference/business-solutions/events/skills/manage-events) — registration settings, guest limit, waitlist
365
+ - [Manage Event Tickets](https://dev.wix.com/docs/api-reference/business-solutions/events/skills/manage-event-tickets) — ticket types and prices
366
+ - **Events Form**: [REST](https://dev.wix.com/docs/api-reference/business-solutions/events/event-management/form) — the questions guests answer