How to Build Secure Workspace Invites with Clerk: Owners, Members and Invite Links

If you're building a SaaS app where people need their own workspaces, can add members to them, have a designated owner, and you want all of it done securely with an auth provider like Clerk, this post is for you.

Written in October 2026. Clerk's features, settings and limits are described as they stood that month.

Cosmic built this for ecco, an agent work coordinator: a shared task board where people and their AI agents work in the same workspace. Everything below came out of shipping it to production, including five bugs we hit along the way.

A secure invite follows six rules

Most invite bugs are one of these rules missing. Check your design against the table before you write any code.

Store only a hash of each code, never the code itself. If your database leaks, the open invites don't leak with it.

Clerk models workspaces as organizations

In Clerk, a workspace is an organization. People belong to it through a membership, and each membership has a role.

Two settings carry most of the security:

• Creator's initial role. Whoever creates an organization gets this role. Set it to Admin, and the creator becomes the owner.
• Default membership limit. Clerk caps how many people an organization holds, and the cap counts pending invitations. Set it to your plan's seat limit.

Clerk's two built-in roles, Admin and Member, are enough for "one owner, everyone else a member". As of October 2026, custom roles are a paid Clerk feature, so we kept to the two built-in ones: the creator is the only Admin, everyone invited joins as a Member, and the app never offers Admin. That also means no one can remove the owner.

One rule on your server: check membership with Clerk's API, not with role claims in the session token. A token can be up to a minute old. A removed member should lose access on their next request, not after the token expires.

Clerk's email invitations need email sign-up

Clerk's built-in invitations send an email with a link. They work well when your app signs people up by email. They stop working in two cases.

First, they need email addresses turned on for sign-up. With email sign-up off, Clerk refuses every invitation, even one that sends no email: "Invitations are only supported on instances that accept email addresses."

Second, they need Clerk to send the email. During heavy testing before an OpenAI plugin submission, Clerk paused email and SMS sending for our production app. We moved sign-up to Google and GitHub, which need no emailed code, and that switched invitations off with it.

How to build invite links, step by step

An invite link adds the person through Clerk's membership API instead of an invitation. The owner shares the link however they like, and the person joins with whatever account they sign in with.

1. Generate the code on your server. Use a cryptographic random source and at least 80 bits: we use 16 characters of Crockford Base32, which also avoids look-alike letters. Show it to the owner once.
2. Store only its hash, with the workspace, the role, who created it and an expiry. Seven days is a sensible default.
3. Let only the owner create, list and revoke codes. Take the workspace from the owner's verified session, never from the request body.
4. Redeem in one database transaction. Look the code up by its hash and lock that row, so two people can't both use it. Refuse used, revoked and expired codes with the same answer.
5. Check the seat limit under a per-workspace lock, then add the person with Clerk's membership endpoint (POST /organizations/{organization_id}/memberships) and the code's role.
6. Record the membership in your own database before you commit, and mark the code used. If anything fails after Clerk added the person, remove them from Clerk again, so a failed redeem never leaves a member you didn't record.
7. Rate-limit redemption per address before any lookup. We allow 10 tries a minute, which is plenty for someone pasting a code and far too few to guess one.

The handler is a few hundred lines with its tests. The tests matter more than the handler: used, expired, revoked, a full workspace, two people racing for one code, and a failure after Clerk added someone.

Five bugs you'll hit, and the fixes

1. A brand-new account can't redeem anything. Clerk puts a new account in a pending state until it has an organization, and Clerk's own docs say a pending session is "by default, treated as signed-out". So your middleware turns away the one request that would finish the pending step. Accept pending sessions on the redeem route only (in Clerk's Next.js SDK, auth with treatPendingAsSignedOut set to false), and keep refusing them everywhere else.

2. Validation runs before authentication. Most frameworks check the request body before your handler checks the session. An unsigned request then gets a validation error instead of 401, which confirms the route exists to anyone probing it. Verify the session first, then read the body.

3. Two people use one link at the same moment. Without a row lock, both pass the "unused" check and both join. Lock the code row for the whole redeem, and lock the workspace while you count seats.

4. A Clerk outage looks like an invalid user. If your code treats every non-200 from Clerk as "this person isn't a member", a short Clerk outage logs everyone out at once. Treat 404 as a verdict about the person, and treat timeouts and server errors as "unavailable, try again".

5. A member can rename the workspace. Clerk's docs say the Member role can only read members and billing by default. On our production instance it also held the "manage organization profile" permission, so the first member we invited could rename the workspace. Your app's checks can be right and still let this through, because Clerk enforces the role as configured. Open Roles & Permissions in the Clerk dashboard, or read the roles from Clerk's API, and confirm what Member actually grants before you invite anyone.

Check these before you ship

• The creator's initial role is Admin, and the membership limit matches your plan.
• Membership is checked with Clerk's API, not token claims.
• The Member role grants only what you expect: read members and billing, no profile changes.
• Codes are random, at least 80 bits, hashed at rest and shown once.
• Codes work once, expire and can be revoked by the owner.
• Redeem locks the code and the workspace, and undoes the Clerk add on failure.
• Only the redeem route accepts pending sessions.
• Unsigned requests get 401 before any validation.
• Redemption is rate-limited per address.
• A Clerk outage returns "try again", never "signed out".

If I did it again, Clerk all the way. It handled organizations, roles and sessions well. The invite flow was the one place where the default path didn't fit our app, and the membership API made the custom path short.