useSendPasswordResetEmail

const { send, isPending, isSuccess } = useSendPasswordResetEmail();

await send(email);

{
  isSuccess && <p>If an account exists for {email}, a reset link is on its way.</p>;
}

Returns

send(email) resolves to { success: true } or a failure result.

isSuccess flips true after a send. reset() returns to idle and clears the error — useful for a retry-with-a-different-address form. Also exposes status, isPending, and error.

Notes

Phrase the confirmation so it doesn't reveal whether an account exists, as above.

Sending it yourself

By default the link is sent from the browser, which puts an email-sending path outside your own rate limiter. sendEmail replaces the send, so the request goes through your API instead:

const { send, isSuccess } = useSendPasswordResetEmail({
  sendEmail: ({ email, actionCodeSettings }) =>
    requestPasswordReset(email, actionCodeSettings),
});

The hook keeps everything else: status, isPending, isSuccess, error and reset behave identically, and a throwing sender surfaces as an ordinary failure result.

The sender receives { email, actionCodeSettings } — the same two things Firebase's own sendPasswordResetEmail takes, and the same two the Admin SDK's generatePasswordResetLink(email, actionCodeSettings) wants on your server. So the actionCodeSettings you set once on the provider still decides where the link lands, even when your API sends it.

Same option, same semantics, on useSendEmailVerification and useEmailLinkSignIn. To set all three at once, use the provider's senders — a hook's own option still overrides it, and null opts that one flow back to Firebase.

Options