Skip to main content
User Account

Verifying Your Email and Phone — the Verification Cards

Where to find it

Both on your Main Hub (/dashboard/) and on Account Settings → Overview (/user/account/) you'll see two cards — Email and Phone. The color tells you everything at a glance:

  • Green card — verified. Nothing to do.
  • Red card — action needed, and every tool you need is inside the card itself.
  • Dashed card — phone not added yet (optional; adds bonus features).

Inside the red email card

  1. Email me the code — sends a fresh 6-character code to your address (check the spam folder if it doesn't arrive within a minute).
  2. Code box — type the code right there and press Verify. No hunting for a separate page. Letters or numbers, any case works.
  3. Change email — if the address is wrong, fix it first; a new address must be verified again, and an address already used by another account is rejected.

After verifying (or resending), you land right back on the page you were on.

Phone system master switch (admin)

The ENTIRE phone system is gated behind one admin switch at /adminapp/communication-settings/sms/ (“Phone System Master Switch”). While OFF (the default), users see no phone card, no add-phone or verify-phone pages — only email verification. Turn it ON after an SMS provider is chosen and configured; the page lists provider price comparisons and warns that the built-in scaffold only prints codes to server logs. Saved numbers survive toggling.

Phone card

Same idea for US numbers: Text me a code, then the code box right in the card. Adding a number supports any country (United States listed first) — but verification texts can currently reach US numbers only, so numbers from other countries are saved to the profile and shown in a calm “Saved” card until SMS coverage expands. Once nothing needs the user's action, the Main Hub collapses the cards into a slim green strip so the workspace stays clean — the Account page keeps the full cards.

For developers

  • Shared partial: userapp/templates/userapp/_verification_cards.html (include with card_next = "hub"/"account", optional compact_verified).
  • Embedded forms carry a next field; _verification_next() in userapp/views.py maps it to named routes only (no open redirect).
  • Tests: userapp.tests.VerificationCardsTests (10).

Real SMS delivery (2026-08)

Phone verification codes are no longer print-only. userapp/sms.py::send_sms posts to the Twilio REST API with plain requests (no SDK) when three things exist: the TWILIO_ACCOUNT_SID and TWILIO_AUTH_TOKEN environment variables on Render, and the From Number saved on /adminapp/communication-settings/sms/. With any of them missing, behavior is unchanged — codes print to the server console and nothing is charged (safe in dev/CI).

Cost guards (active only while Twilio is live — scaffold mode keeps the old unlimited behavior): add_phone refuses a 4th code request within one hour, counted per user AND per phone number under a per-user row lock, and enforces a platform-wide daily ceiling (userapp/sms.py::GLOBAL_DAILY_CAP) against SMS pumping. Caribbean premium +1 ranges (Jamaica, Dominican Republic, …) are excluded from the US code flow in userapp/phones.py::phone_is_us. A failed Twilio send deletes its unused code row (no quota burn) and shows a friendly retry message. Admins should additionally enable Twilio's SMS Pumping Protection + US-only Geo Permissions — steps on the SMS settings page.

Admin setup: click-by-click steps live on the SMS settings page and as Setup Checklist task SMS-1 (probe key sms_delivery turns green automatically when credentials + From Number are detected). Tests: userapp/test_sms.py.

🪐 OrbitPilot