Auth · Email
Email registration, sign-in, recovery and verification, plus every account mail the module sends.
Email as an identifier and email as a channel. The first half of this reference registers, signs in and recovers accounts by address; the second half sends the mail that makes those flows work.
Challenge, then complete
Registration, sign-in and recovery are each a pair. A POST …/challenge mails a link or a code; the
matching POST redeems what came back and returns a session. Nothing is created until the second call,
which is what makes the address proven rather than merely typed.
Every challenge answers 200 whether or not the address has an account. That is deliberate: an endpoint
that answered differently would be a way to find out which addresses are registered.
Sending mail directly
The notification routes are admin-guarded and send one specific message each. All of them take
?preview=true, which renders the message and returns it as HTML instead of sending it — the way to see
what a template produces without mailing anybody.
Not implemented
Three routes under …/verification answer 501. They are documented here because a
501 you were not expecting costs more time than one you were told about. Verifying an address on an
existing account works through the identity routes.