# Create RSVP (POST /events/v2/rsvps) returns empty-body 403 with a Site API key — which identity does it require?

**URL:** <https://forum.wixstudio.com/t/create-rsvp-post-events-v2-rsvps-returns-empty-body-403-with-a-site-api-key-which-identity-does-it-require/79109>\
**Category:** Ask the community\
**Tags:** api, wix-events, wix-headless, code, wix-apps-market\
**Created:** [July 27, 2026, 12:12pm UTC](https://forum.wixstudio.com/t/create-rsvp-post-events-v2-rsvps-returns-empty-body-403-with-a-site-api-key-which-identity-does-it-require/79109 "2026-07-27T12:12:12Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![sam\_nazarko](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sam\_nazarko](https://forum.wixstudio.com/u/sam_nazarko)\
**Post date:** [July 27, 2026, 12:12pm UTC](https://forum.wixstudio.com/t/create-rsvp-post-events-v2-rsvps-returns-empty-body-403-with-a-site-api-key-which-identity-does-it-require/79109/1 "2026-07-27T12:12:13Z")

</div>

I’m building a headless integration (Cloudflare Worker backend) where our app is the registration front-end and Wix Events is the system of record. The backend calls the Events REST API with a **site API key**. Reads work; **creating an RSVP fails with an empty-body 403** , and I’d like to know which identity the endpoint actually requires before I rebuild the auth layer.

Setup:

- Endpoint: `POST https://www.wixapis.com/events/v2/rsvps`
- Auth: site API key (API-key-admin identity) with Manage Events permission
- Event: RSVP-type, registration status OPEN, default form (firstName, lastName, email — confirmed via GET `/events/v1/events/{id}/form`)
- Site ID: `2134eadf-3402-41bb-99d1-9e25b4bc633a`
- Response: `403 {"message":"","details":{}}`
- Response headers: `x-wix-responded-by: wix.events.v2.rsvp:CreateRsvp`, `x-wix-request-id: 1784846282.35218850752431378`

What I’ve verified and ruled out:

- **Not policies** — Query Policies returns none for the event.
- **Not permissions in general** — the same key writes fine to the Form Submissions API (200) and all Events reads work.
- **Not endpoint version** — v2 is correct; the v1 path `/events/v1/events/{id}/rsvp` 404s.
- **Not body shape** — with the flat guest fields present I get the empty 403; omit them and I get a clean 400 “firstName/lastName/email must not be empty”. So the payload is accepted and validated; the 403 is an authorization/business-rule refusal, not a validation error.

My questions:

1. Does `POST /events/v2/rsvps` (Create RSVP) support being called by a **site API-key admin identity** to register a guest, or is it restricted to a **Wix app** / **visitor** / **member** identity?
2. If a site API key can’t create RSVPs, what’s the recommended way for a trusted backend (no Wix login for the guest) to register an attendee on an RSVP-type event? Is authenticating as a **Wix app instance via OAuth** the right path, and does that identity get accepted by Create RSVP?
3. Could someone check request-id `1784846282.35218850752431378` for the exact reason behind the empty-body 403?

Thanks — a definitive “which identity does Create RSVP accept” would unblock this. Happy to provide anything else needed.

Many thanks

Sam Nazarko

---

<div class="post-metadata">

**Author:** ![noahlovell](https://sea1.discourse-cdn.com/wix/user_avatar/forum.wixstudio.com/noahlovell/32/118920_2.png) [@noahlovell](https://forum.wixstudio.com/u/noahlovell)\
**Post date:** [July 28, 2026, 12:57pm UTC](https://forum.wixstudio.com/t/create-rsvp-post-events-v2-rsvps-returns-empty-body-403-with-a-site-api-key-which-identity-does-it-require/79109/2 "2026-07-28T12:57:43Z")

</div>

Did you manage to figure this out?

I took a quick look, and it seems that the caller had missing or incorrect permissions. It’s worth double checking that the permissions granted are actually granted (I know I’ve forgotten to hit save etc in the past before 😅)

Are you able to share a little more about your setup? Are you using Headless, or something else? Where is the API key created from (e.g. within the site itself, or at the level of your Wix account)

---

<div class="post-metadata">

**Author:** ![sam\_nazarko](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sam\_nazarko](https://forum.wixstudio.com/u/sam_nazarko)\
**Post date:** [July 28, 2026, 1:47pm UTC](https://forum.wixstudio.com/t/create-rsvp-post-events-v2-rsvps-returns-empty-body-403-with-a-site-api-key-which-identity-does-it-require/79109/3 "2026-07-28T13:47:18Z")

</div>

Hi,

I haven’t been able to resolve this yet, but I’ve tried opening a support ticket.

The API key is generated under the Wix site. It’s a standard site (not headless). Permissions only seem to be on/off, rather than fine grained. I believe the correct permissions (Manage Events) as well as ticketing are enabled.

---

<div class="post-metadata">

**Author:** ![sam\_nazarko](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sam\_nazarko](https://forum.wixstudio.com/u/sam_nazarko)\
**Post date:** [July 28, 2026, 11:53pm UTC](https://forum.wixstudio.com/t/create-rsvp-post-events-v2-rsvps-returns-empty-body-403-with-a-site-api-key-which-identity-does-it-require/79109/4 "2026-07-28T23:53:10Z")

</div>

### Resolved — and it was the event, not the credentials

Posting the answer in full since the thread went a long way down the wrong road, and the failure mode is genuinely misleading.

**Cause:** the event I was testing against had been **converted** from EXTERNAL registration to RSVP, rather than created as an RSVP event. That specific event refused `POST /events/v2/rsvps` with an empty-body 403, permanently and reproducibly. The site owner deleted it and created a fresh event as RSVP-type from the outset. The identical request, with the identical site API key and unchanged code, succeeded immediately.

**What this means for the original question:** a **site API key is perfectly capable of creating RSVPs**. No registered Wix app, no OAuth, no app identity, no SDK. The `Authorization: <api key>` plus `wix-site-id` header pair is sufficient, over plain `fetch`.

#### Everything that was wrongly suspected first

Documenting these because each looked plausible and each cost time:

- **Request body** — I was sending the documented Create RSVP example verbatim (flat `firstName`/`lastName`/`email`, `form.inputValues` with all three, `status: "YES"`). Correct all along. Omitting the flat fields returns a clean 400 naming them, so the payload was validating; the 403 only appeared once the request was well-formed, which strongly implied an authorisation decision.
- **Endpoint version** — v2 correct; the v1 path 404s.
- **Policies** — Query Policies returned none for the event.
- **Permissions** — the same key read Events fine and wrote successfully to Form Submissions (200).
- **Identity** — the RSVP v2 reference states these methods require a “Wix app or Wix user identity”, which I took as excluding API keys. That reading was wrong, and the giveaway should have been that Get and Query RSVP carry the same note yet worked with the same key. I noticed the contradiction and set it aside rather than following it.
- **SDK vs REST** — the official SDK with `ApiKeyStrategy` failed identically, which I misread as confirming an identity problem. It only showed the failure was upstream of request construction.

**What was never checked: whether the event had been converted rather than created.** I’d verified it was RSVP-type and open and stopped there.

#### Two bugs worth someone’s attention

1. **A converted event ends up unable to accept API RSVP creation** , while remaining indistinguishable from a working event through the API. `registration.type: RSVP`, `status: OPEN_RSVP`, `registrationPaused: false`, `registrationDisabled: false`, `getForm` returns a normal two-control form, Query Policies returns none. There’s no field exposed that would let a developer detect this state. Given the docs say ticketed and RSVP events can’t be converted between types, it may be that EXTERNAL→RSVP shouldn’t be permitted either — or should fully migrate the event’s state.
2. **The 403 returns an empty `message` and empty `details`.** This is the real cost. The endpoint returns rich `validationError.fieldViolations` for a bad payload, so the same service clearly can produce detailed errors — but the authorisation path returns nothing. With no reason, the only available strategy is guessing, which is how a configuration problem became a multi-week investigation into auth models. Almost any message would have ended it: “event not eligible for RSVP creation”, or even a bare “event state invalid”.

Thanks to everyone who weighed in, and apologies for the wild goose chase on identity.

**For anyone finding this via search: if `POST /events/v2/rsvps` returns a 403 with an empty body, check the event before you doubt your credentials.** Create a brand-new RSVP-type event and try that first — it takes two minutes and would have saved me some time

Cheers

Sam

---

<div class="post-metadata">

**Author:** ![noahlovell](https://sea1.discourse-cdn.com/wix/user_avatar/forum.wixstudio.com/noahlovell/32/118920_2.png) [@noahlovell](https://forum.wixstudio.com/u/noahlovell)\
**Post date:** [July 29, 2026, 11:12am UTC](https://forum.wixstudio.com/t/create-rsvp-post-events-v2-rsvps-returns-empty-body-403-with-a-site-api-key-which-identity-does-it-require/79109/5 "2026-07-29T11:12:55Z")

</div>

Thanks for taking the tip to loop around with the solution!

To echo the discussion in Discord, it seems that this was both the permissions issue (which we solved), and then also this issue you found. We’re working on updating the docs to reflect this 🙂

---

<div class="post-metadata">

**Author:** ![system](https://sea1.discourse-cdn.com/wix/user_avatar/forum.wixstudio.com/system/32/86885_2.png) [@system](https://forum.wixstudio.com/u/system)\
**Post date:** [August 28, 2026, 11:13am UTC](https://forum.wixstudio.com/t/create-rsvp-post-events-v2-rsvps-returns-empty-body-403-with-a-site-api-key-which-identity-does-it-require/79109/6 "2026-08-28T11:13:13Z")

</div>

Closed on August 28, 2026, 11:13am UTC

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
