Given an invitation id, token or email, it returns the raw invitation row with its account, the computed expiry and status, every identity-provider user matching that email (which catches the duplicate-account case), each of their metadata values, any crew roster rows keyed to matching user ids, and whether the invitation's crew actually exists. Authorised to the admin of that invitation's account, or the platform owner.
Also called: why is this invite still pending · invite troubleshooting · duplicate account · why is the invite stuck
- 1Accepts ?invitationId=, ?token= or ?email=.
- 2Reads the invitation row and computes expiry and effective status.
- 3Looks up every identity-provider account matching the invitation email, not just the first.
- 4Returns each account's role, crew, status and account attachment.
- 5Returns crew roster rows for any matching user id and the crew row for the invitation's crew id.
- 6Authorisation is the invitation's account admin, or the platform owner.
The comment explains why logs weren't enough: 'Vercel function logs are great when the handler fired and threw, but useless when the handler silently succeeded with a bad write (e.g. the invitations.update returned an error but we didn't check it). This endpoint exposes the post-conditions so you can tell the difference.' It is aimed at a named class of bug — someone who 'signed up but still shows pending' — and specifically catches the duplicate-account case 'where the user has two Clerk users for the same email or signed up with OAuth under a different one.'
- A silently failed write looks identical to a user who never signed up.
- Duplicate identity accounts for one email are invisible from the team list.
- Support had to guess rather than inspect.
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 →