Two channels reach your attendees: automatic transactional emails fired by the state of their RSVP, and an in-app notification that lands alongside every one of them. You only manually trigger a couple of things yourself — mainly Broadcast.
Automatic attendee emails
There are roughly 30 distinct email templates covering the attendee lifecycle end to end — you don't send these, they fire the moment the underlying state changes:
- Signup confirmation code
- RSVP / ticket confirmation, with QR code attached
- Payment reminders for an unpaid pending RSVP
- Waitlist offers when a seat opens up
- "Spot opened" nudges for interested signals
- Cancellation and refund notices
- Check-in-method-changed notices (see Check-in modes for exactly when this one fires)
- Order-adjustment top-up payment links, when you add a paid item to a confirmed order
- Co-host invites, transfer requests, walk-in receipts, and more
None of these need you to do anything — they're triggered by the state change itself (payment verified, RSVP cancelled, waitlist spot freed, and so on), not by a button you press.
The notification bell
Every one of those state changes also writes a matching in-app notification — the bell icon and unread badge in the nav, with full history at /notifications. There are 11 notification types: event updated, spot opened, event reminder, payment pending, broadcast, RSVP confirmed, RSVP removed, moved to waitlist, moved to interested, event cancelled, and offer expired.
This is a genuine backup, not a duplicate for its own sake. The notification is created in the same database transaction as the state change — it doesn't wait on the email actually sending. So if an email bounces, lands in spam, or the attendee has unsubscribed from your broadcasts, the bell notification still lands.
What you trigger yourself
Broadcast — a one-off message to attendees, from your event page's Broadcast button. You pick an audience before you can send anything (there's no default, so a send can never go out to a pre-selected list by accident):
- Confirmed — only confirmed RSVPs
- Pending payment — RSVPs awaiting payment verification
- Active — confirmed + pending payment combined
- Interested — interested signals only
- Everyone — active + interested
Subject is capped at 100 characters, body at 4000. A Preview button renders the actual email template — cover image, subject, your paragraphs, the event card, and the unsubscribe footer — before you commit to sending.
Rate limits are scoped per recipient list, not per event, so messaging Confirmed doesn't block you from also messaging Interested the same day:
- At most 5 sends per list in a rolling 24-hour window. The next slot opens 24 hours after the oldest send still inside that window — not a flat once-a-day reset.
- A lifetime cap of 20 broadcasts per recipient list per event.
After a send, the result card breaks down what happened: attempted, delivered, skipped for unsubscribe, skipped for no resolvable email address (undeliverable), and failed. Failed sends (typically a transient rate-limit from the email provider) get a Retry failed button that re-attempts just those recipients, paced so it doesn't immediately re-trip the same limit. Every broadcast — subject, body, audience, and counts — is logged to the event's send history, visible to you and any co-hosts.
Where attendee replies go — a reply to a Broadcast email doesn't just disappear. Where it lands depends on the contact channel you've set for the event:
- Preferred contact is email (or nothing set) — the reply goes straight to your inbox, the same as before.
- Preferred contact is a social channel (X, Instagram, Discord, etc.) — Offkai relays the reply to your account email instead, without ever revealing your address to the attendee. The relayed message arrives with the attendee's own email in Reply-To, so you can respond straight back to them. If you do reply from your own inbox, though, that attendee will see your address — the masking only covers what Offkai sends.
This works automatically — it's based on whichever contact channel you already picked for the event. If you'd rather not receive relayed replies for a particular event, turn off Attendee replies to broadcasts in the email notification settings on that event's host page; replies attendees send while it's off aren't emailed to you.
Check-in mode change notice — if you switch an event's check-in mode after it already has confirmed attendees, and the change involves QR mode (switching to or from it), you're asked whether to notify them. See Check-in modes for the exact default behavior.
Unsubscribe scope — narrower than it sounds
Unsubscribing is per event and only applies to Broadcast messages. An attendee who unsubscribes from one event's broadcasts:
- Still gets their ticket, payment reminders, cancellation notices, and every other transactional email for that same event.
- Isn't opted out of any other event they've RSVP'd to — the unsubscribe doesn't carry over.
There's currently no per-type email preference control anywhere in the app — no way for an attendee to turn off, say, payment reminders while keeping their ticket email. It's all-or-nothing, and it only governs Broadcast.
See Email notifications & unsubscribing for the attendee's-eye view of what they receive and how they opt out, and Waitlist & seat offers for how the waitlist-offer and spot-opened emails specifically fit into managing a capped event.