The endpoint
email is required.
It is open to any origin on purpose — that is what makes it work from a static site
you host anywhere, with nothing to configure. The design follows from that:
It grants nothing
It grants nothing
A request is a row on a list. Nothing on that list has access to anything until an
admin presses Invite.
It never reads anything back
It never reads anything back
There is no read side. The endpoint accepts and answers.
It answers identically either way
It answers identically either way
The response is the same whether or not an address is already on the list, so it
cannot be used to find out who signed up.
Junk is cheap to keep out
Junk is cheap to keep out
A honeypot field, a unique index on the address and a burst ceiling handle the obvious
cases. Anything that gets through is one click to delete.
Working the queue
Who asked for access this week?
admin_list_waitlist returns each request with the address, what they said they are
looking for, which site they came from, and when they asked. Entries already turned into
invites are included with an invitedAt date, so the list is the whole history — pass
pendingOnly: true for just the queue. Reading it tells nobody anything.
admin_invite_waitlist_signup turns a request into a real invitation: creates the invite,
emails it, and marks the request as invited so it leaves the queue. It takes the signup
id, not an email address. If email is not configured the invite is still created and the
reply carries a link you can send by hand.
The row stays afterwards, stamped with the date, so the list remains a record of who asked
and when.
admin_remove_waitlist_signup deletes a request for good — spam, a duplicate, or somebody
who asked to be taken off. It does not revoke an invitation that was already sent; that
is admin_revoke_invite. Irreversible, so read the list first and remove by id.