Repository navigation
Account: complete the email-change flow (verify and undo) #72
Description
Part of #71 — Account lifecycle & security completeness
POST /api/user/change-email/request is wired, but the two endpoints that finish the flow are
not:
POST /api/auth/verify-email-change— confirm the new address from the emailed link.POST /api/auth/undo-email-change— the safety valve if the change was not the user's doing.
Today an Android user can start an email change and then has to finish it on the web.
- Deep-link handlers for both emailed links, plus an in-app pending-change state showing the
address awaiting verification with resend and cancel.
Tests: deep-link parse for each; pending state renders and clears.
Filed from the parity review of feature/parity-wip @ 14d7795 against interlinedlist.com (OpenAPI /api/openapi.json, 233 paths) and the public help centre.
Activity
Adron commentedon Sep 16, 2026
Implemented in the PR above (branch
issue/72-account-email-change). Closing here — review and any follow-up happens on the PR.Two things need your confirmation, both carried into the PR:
The emailed link URLs are derived, not documented.
GET /verify-email-change?token=…andGET /undo-email-change?token=…both return 200 and render "Invalid Verification Link" / "Invalid Undo Link", while/auth/verify-email-change,/email-change/verify,/account/verify-email-changeand/change-emailall 404 — so the paths match the existing/verify-emailand/reset-passwordconvention. Please check against the actual mail templates.The "cancel" action this issue asked for does not exist in the API, so I did not ship a fake button.
DELETE /api/user/change-email/requestreturns 405 (the route is POST-only), andPOST /api/user/change-email/cancel,DELETE /api/user/change-emailand apendingEmailfield onPATCH /api/user/updateall 404 or are absent. The product's real safety valve isundo-email-change, which needs the token from the email — so the banner explains that instead of pretending to offer cancellation.Worth a separate look: the help page documents
POST /api/user/change-email/requestas{ newEmail, password }, but the spec and the already-shippedChangeEmailRequestsend onlynewEmail. If the server really requirespassword, the existing change-email request is already broken — not something this issue introduced.merge: #72 email-change verify/undo (PR #108)