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

Ask the community
, , , ,
1

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

2

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 :sweat_smile:)

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)

3

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.

4

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