Invite to RSVP

The rejection — uninvited guest tries to access the RSVP page

Trigger: someone forwards their invite link to a friend, OR a bot probes /p/<event-slug>/rsvp?token=... with a guessed token, OR the link gets posted publicly. The token doesn't validate (signature mismatch, no matching guest, or guest is on a different event).

The dignified-rejection contract. The page does not 404. It does not show a hostile error. It shows a clear, courteous explanation:

• Page H1: "This invitation isn't valid for this account" (or "This event is invitation-only" if the token is structurally absent).
• One sentence of context: "<Event name> is a private event. Invitations are personal and can't be shared."
• If the event has a public-facing description (organizer enabled "show event title to non-invitees"): the title and date are shown so the recipient can verify they were trying to access the right event. If not: no leak — just the message.
• A primary action: Request an invitation. Clicking opens a form (uses ui-form) asking for the requester's email and an optional message. Submission goes to the organizer for approval, NOT to the public page.
• A secondary action: Already invited? Try a different link — leads to a help page explaining the invite link is personal and what to do if they've lost theirs.
• NO retry button, NO error code visible to the user, NO mention of why specifically the token failed (signature vs expiry vs unknown guest — that's diagnostic info that helps probing).

The tone matters as much as the mechanics. The page is warm, not hostile. The user did nothing wrong; they're just not on the list. Visual style is muted, not red-alert. Color contrast still meets WCAG-AA throughout.

Recovery: Request access via the form. If the organizer has the request, they can issue a new invitation through the audience tools.

Expired invite

Trigger: the event has passed, OR the organizer set an invitation expiry that has elapsed.

The page shows a different message: "This invitation has expired." The event title and date ARE shown (since the recipient was confirmed-invited; we already knew them). If the event has passed, the page offers to add a follow-up email subscription if the organizer enabled future-events-list. If only the invite expired but the event is upcoming, the primary action is Request a new link — sends a request to the organizer to re-issue.

Recovery: Request a new link; organizer can reissue or update the expiry.

Already accepted — re-click invite link

Trigger: guest accepted yesterday, clicks the invite link again today.

The page recognizes the token + the existing status=confirmed row. Shows the confirmation card directly: "You're confirmed for <Event name>" with calendar links, QR, and event details. Below: an option to Change my response if the event still allows it (organizer config). Re-clicking does NOT re-accept (no double-acceptance).

Recovery: No action needed. The guest is reassured they're confirmed.

Already declined — re-click invite link

Trigger: guest declined last week, changes their mind, clicks the invite link.

The page recognizes the existing status=declined row. Shows: "You declined <Event name> on <date>. Would you like to update your response?" If the event allows status changes (organizer config; default yes until N days before event): the Accept button is offered. If declined-locked: a message explains why ("Responses can no longer be changed; contact the organizer if needed").

Recovery: Update response, or contact organizer.

Capacity full when guest tries to accept (FCFS race)

Trigger: organizer sent invitations for an FCFS access type with capacity = 50. The 51st guest tries to accept; the slot is gone.

The page shows: "<Event name> is now at capacity. We've added you to the waitlist — you'll be notified if a spot opens." The system creates a status=waitlisted row. The guest does NOT see a hostile error or "you missed it." Waitlist position is visible (guest is #3 on the list), so they have realistic information about likelihood.

Recovery: Waitlist; auto-promotion if a confirmed guest cancels (EF-025).

Token tampering — signature invalid

Trigger: someone modifies the token query parameter (changing one character, etc.).

Server's HMAC verification fails. The page shows the same "This invitation isn't valid" message as the rejection failure mode — does NOT distinguish a tampered token from an unknown one. Distinguishing would help an attacker probing for valid token formats. Logged server-side at higher severity than a normal rejection so security can flag suspicious patterns.

Recovery: Same as the rejection failure mode — Request an invitation.

Guest tries someone else's invite link

Trigger: Alice forwards her invite link to Bob. Bob clicks; the page loads with Alice's name pre-filled in the RSVP form.

This is technically the happy path from a security perspective — the token is valid, the guest record is for Alice, the page renders Alice's RSVP form. Bob sees Alice's name in the field. The page does NOT auto-send an "Alice accepted" if Bob clicks Accept — but it WILL register Alice, not Bob. This is a forwarding-detection moment, not a rejection.

To handle Bob: the page includes a small "Not Alice? Request your own invitation" affordance. Clicking takes Bob through the request-invitation flow. The page does NOT prompt Bob to enter his email "instead of Alice" — that would let him trivially accept-on-behalf-of-Alice. The invitation belongs to Alice and only Alice.

Recovery: Bob requests his own. Alice's invite is unaffected.

Invitation email bounced — guest never knew they were invited

Trigger: invitation email bounces (full mailbox, dead address, spam-blocked). The organizer's deliverability report (EF-089) shows the bounce.

This isn't a guest-side failure mode — it's an organizer-side observability one. The audience view shows guests with their last-email-status pill: delivered, opened, clicked, bounced, declined. Bounced guests are surfaced with a "Resend invitation" affordance and an option to update their email address. The guest who didn't receive isn't blamed for not RSVPing.

Recovery: Organizer updates the address and resends, OR removes the guest from the audience.

Network failure during RSVP submit

Trigger: guest clicks Accept; their connection drops; the request fails.

The form (uses ui-form) preserves their selection. Error banner above the form: "Couldn't save your response. Check your connection and try again." Retry sends the same request with the same Idempotency-Key so the server dedupes if the original landed but the response was lost. Guest doesn't accidentally double-confirm or end up in an inconsistent state.

Recovery: Retry. Idempotent.

Plus-one denied for an access type that doesn't allow them

Trigger: invitation didn't grant plus-ones, but the guest tries to add a +1 in the form.

The plus-one field is hidden when not allowed — not shown disabled. (Showing-disabled invites the question "why can't I?" which we can't always answer well.) The guest only sees fields that apply to their invite. If the organizer DID grant +1: the field is visible, with a count limit if applicable, and the +1's name + email are required.

Recovery: N/A — the +1 affordance simply isn't shown when not allowed.

Organizer revokes an invitation while guest is mid-RSVP

Trigger: guest opened the RSVP page 5 minutes ago. While they were composing their response, organizer revoked the invitation.

Guest clicks Accept. Server returns 410 Gone with code INVITATION_REVOKED. The page transitions to the rejection state with a softened message: "Your invitation was withdrawn before you could respond. If you think this was a mistake, please contact the organizer." Their composed response is shown back to them ("You were going to say: '<message>'") so they don't lose what they wrote — they can copy it for an email to the organizer.

Recovery: Out-of-band — contact the organizer.

Event was archived between invite-send and click

Trigger: organizer archived the event. Guest clicks invite link a day later.

Page shows "<Event name> is no longer available." with the event date. If a follow-up email subscription was enabled, an option to subscribe. No "request invitation" affordance — the event is gone, can't reissue.

Recovery: Subscribe to future events, or move on.