Invite-Only Event Registration: How to Restrict Sign-Ups to People You've Actually Invited

You post a link to a partner advisory board meeting, an executive briefing, or your association's annual member meeting. You didn't advertise it publicly — but somehow, someone who was never supposed to see it shows up on the attendee list. Someone forwarded the "private" link, or it got indexed, or a well-meaning employee shared it in the wrong Slack channel. Once a registration link is out there, anyone who has it can register, whether or not they were supposed to.

That's the real problem with most "private" event pages: they aren't actually private. They're unlisted, which is a very different thing from restricted. Invite-only event registration solves this by gating sign-up against a specific list of approved people, so someone without an invite can't register — even if they have the exact URL.

What "invite-only" actually means, mechanically

In Sunfish, invite-only registration isn't a workaround you build with hidden pages, password-protected PDFs, or a registration form you manually police afterward. It's a toggle. When you turn it on for an event, registration is gated to people who are already on one of your Contact Lists — specifically, an Invite and Promote list you've built for that event or reused from a previous one.

Here's what that means in practice: if someone's email address isn't on the invite list attached to the event, they cannot complete registration. It doesn't matter if they find the link in an old email, a calendar invite that got forwarded, or a link someone pasted into a group chat. The form simply won't let them through. This is the core difference between "invite-only" and "unlisted" — an unlisted link is security through obscurity, and it fails the moment obscurity fails. A true invite-only event registration checks every registrant against a list before anything is submitted.

Because the gating happens against your existing Contact Lists, the invite list you use for one event doesn't have to be rebuilt from scratch for the next one. If you're managing a recurring series — a quarterly partner briefing or an annual member meeting — the same list logic that powers segmentation and email campaigns is what powers your restriction. For more on how these lists work across multiple events, see reusable invite lists for every event.

Adding login: verifying identity before anyone sees the form

The invite-list toggle controls who can register. Pairing it with login controls who can even see the registration form in the first place. This is an optional second layer, and it matters for a specific kind of event: the ones where the content behind the form — not just the guest list — needs protecting.

Here's the mechanical difference. With invite-only registration alone, an invitee can click the link and land straight on the form, fill it out, and submit — Sunfish checks their email against the invite list at submission and either lets it through or blocks it. With login paired in, invitees have to authenticate first — typically by verifying their email or logging into an account — before the registration form itself becomes visible. Nobody who hasn't verified their identity ever sees the fields, the pricing, or any details you've put on that page.

That distinction matters when the registration page itself contains something sensitive. If your form displays member-only pricing, references confidential partner terms, or previews board-level agenda details, you probably don't want that visible to anyone who merely has the link, even briefly, before they fill anything out. Login as a gate before the form closes that gap. For B2B organizers running lower-stakes private events, the invite-list toggle by itself is usually sufficient. For higher-stakes ones — where you're gating access to sensitive pricing, partner data, or leadership discussions — pairing it with login is the safer default.

Use cases: what this actually looks like

Invite-only registration is not a consumer party feature (this isn't about Facebook event privacy settings or a plus-one list for a birthday party). It's built for professional events where the guest list itself is the control, and the wrong person seeing the page is a real business risk. A few concrete scenarios:

Executive briefing for named accounts. Your sales or customer success team is running a briefing for a small number of strategic accounts. Only specific named contacts at those accounts should be able to register — not "anyone at that company," not "anyone who heard about it." You build the invite list from your named-account contacts, flip the toggle, and the registration page enforces exactly that boundary.

Association member-only annual meeting. Your association needs a way to restrict the annual meeting (and any member-only voting sessions or business meetings) to current, dues-paid members. Non-members shouldn't be able to register even if a member forwards them the link. This pairs naturally with the kind of member management associations already rely on — see registration for associations for more on how Sunfish handles association-specific registration needs.

Partner advisory board. You're convening a partner advisory council to discuss roadmap and go-to-market plans that shouldn't circulate outside that group. The invite list is small, deliberate, and tightly controlled — exactly the kind of guest list where an unlisted link is not an acceptable substitute for actual access control.

Sales kickoff with internal staff plus specific external guests. Your SKO is mostly internal, but you're bringing in a handful of external guests — maybe a keynote partner or a customer speaker. You need registration open to all internal staff plus that specific external list, and closed to everyone else. Building one invite list that combines both groups handles this without a separate registration process for each audience.

Invite-only vs. an "unlisted" link

Founders and event teams often start with the workaround: don't publish the link anywhere, and hope that's enough. It rarely is, especially once an event has been running for more than one cycle. Here's how the two approaches actually compare:

The unlisted link isn't a security measure — it's an honor system. Invite-only registration is an actual access control, enforced automatically for every registration attempt, not just the first one.

When to use which access mode

Not every private event needs the same level of restriction. Use this as a rough decision guide:

That last row matters. Even a well-maintained invite list can miss someone who should legitimately be there — a new hire, a late addition to a partner team, a member whose renewal hasn't synced yet. If you're worried about being too restrictive, Sunfish has a companion feature, Request Access, that lets uninvited-but-legitimate people ask to be let in without opening registration to everyone. We won't go deep on it here — see Request Access for invite-only events for how that works — but it's worth knowing it exists as the safety valve for this exact tradeoff.

FAQ

Does invite-only registration require people to create an account?
Not by default. The base invite-only toggle checks a registrant's email against your invite list at the point of registration — no account creation required. Login is a separate, optional layer you add on top when you want identity verified before the form is even visible.

Can I use the same invite list for multiple events?
Yes. Invite-only registration checks against your Contact Lists, which are built at the organization level and can be reused across events — useful for recurring briefings, board meetings, or annual member gatherings where the eligible group stays largely the same.

What happens if someone not on the invite list tries to register?
They're blocked at registration, regardless of how they got the link. If you want a way for legitimate-but-uninvited people to ask for access instead of simply being turned away, pair invite-only registration with Request Access.

Key takeaways and next step

Invite-only event registration in Sunfish is a single toggle that gates sign-up against an Invite and Promote Contact List — not a hidden-link workaround that falls apart the moment it's forwarded. Pair it with login when the registration page itself contains something sensitive, like partner pricing or board content, so invitees have to verify their identity before they see the form at all. It's built for professional use cases — executive briefings, partner boards, member-only meetings, restricted sales kickoffs — where the guest list is the control.

If you're running a private event and want registration locked to an approved list without building a custom process, set up your invite list and flip the toggle in your event settings, or reach out and we'll walk through it with you.