The same finalisation that acceptance performs, run with the admin's authority instead of the invitee's session: it finds the identity-provider account by the invitation's email, merges account, role, crew and approved status over their existing metadata, marks the invitation accepted with the user id and timestamp, and upserts the crew roster row for a crew-scoped invite.
Also called: manually accept invite · finalize invitation · fix stuck user · signed up but still pending · invite stuck · fix invite · finalize invite
- 1POST with an invitation id.
- 2The invitation is asserted to be in the caller's account and still pending.
- 3The identity-provider user is located by the invitation's email.
- 4Metadata is merged rather than replaced, so unrelated fields survive.
- 5The invitation row is marked accepted with the user id and used-at timestamp.
- 6Crew-scoped invites upsert the crew roster row.
- 7Authorisation is the tenant admin whose account matches the invitation, or the platform owner.
The header lists the situations it exists for: 'the user opened the invite link, signed up via Clerk, but something between Clerk-signup and /api/invite/accept didn't complete (network drop, browser closed, accept handler threw, cross-claim block tripped, etc). The invitation row stays pending and crew shows them as still INVITED even though their Clerk account exists.' Rather than asking the new hire to re-do a signup they have already done, the admin closes the loop. Merging metadata rather than overwriting is the detail that keeps this safe to run twice.
- A partially completed signup left a real account with no access and no way forward.
- Re-inviting created a second invitation without fixing the first.
- Support intervention required direct database edits.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →