What OddsWatch collects, and how it's used.

What we collect

OddsWatch has a confirmable waitlist flow and a separate legacy landing form. The confirmable flow underneath POST /api/waitlist writes a row to the waitlist_signups table with:

• email — the address you submitted, validated and stored in normalized lowercase form.
• source — which signup form the address came from; it defaults to hero.
• confirmed and confirmation_token — the confirmation state and its 64-character token. The confirmation token is cleared after confirmation.
• unsubscribe_token — a separate 64-character random hexadecimal token generated for the recipient.
• pref_briefing and pref_ev_alerts — the morning-briefing and +EV-alert channel choices, both initially on.
• unsubscribed_at — the timestamp used to suppress delivery after a full opt-out.

The legacy footer form underneath POST /api/landing/signup writes a separate landing_signups record with the email, source tag, and converted / converted_at fields used for funnel analytics. That legacy analytics record is not the confirmable waitlist record described above.

How we use it

Your waitlist email is used to confirm the signup, send the confirmed welcome message, and—when enabled—send the morning briefing. +EV alerts are another email channel; recipient selection uses the relevant signup or subscription record and its channel settings. A confirmation message is sent before confirmation; later waitlist messages depend on the confirmation state and saved preferences.

Preferences are stored per recipient. The delivery paths consult the relevant channel settings when selecting eligible recipients, and a full opt-out suppresses later sends.

Who sends the email

The confirmation email is sent by services/waitlist-email.js through the configured SMTP transport, using the configured SMTP_HOST, SMTP_PORT, SMTP_USER, and SMTP_PASS settings. Its sender is EMAIL_FROM, which defaults to alerts@oddswatch.com when unset.

The confirmed welcome message, morning briefing, and active +EV alert paths use the Polsia email proxy through services/welcome-email.js, services/briefing-email.js, and services/email-dispatcher.js. These are separate delivery paths; not every OddsWatch message uses the same transport.

Delivery activity is audited where those paths provide audit records: morning briefings use morning_brief_deliveries, and +EV alerts use email_deliveries. Those records contain recipient and delivery-status metadata (and, when applicable, a response message); they do not store the email body.

How to opt out

The current morning-briefing and +EV-alert email templates can include a "Manage preferences or unsubscribe" footer link. Confirmation and welcome messages do not make that same preference-footer promise. When present, the link carries the stored unsubscribe_token: an opaque, per-recipient 64-character random hex value checked by exact database match. It is not a cryptographic signature.

GET /unsubscribe/:token renders views/preferences.ejs. A valid waitlist token shows the recipient's email and the two channel toggles; the browser posts either { token, briefing, ev_alerts } or { token, unsubscribe: true } to POST /api/preferences.

1. Both channels off — sets unsubscribed_at and suppresses later sends.
2. A channel turned back on — clears unsubscribed_at so delivery suppression is removed.
3. Invalid token — shows an actionable error state, and the JSON endpoint returns invalid_token; the page advises replying to an OddsWatch email for help.

Unsubscribing suppresses delivery; it does not delete the waitlist row.

How long we keep it

Unsubscribing does not delete a waitlist_signups row. The current implementation has no automatic deletion route or automatic deletion schedule. For manual deletion or export questions, email privacy@oddswatch.com; the codebase does not promise a deletion SLA.

The separate landing_signups records support legacy funnel analytics and should not be assumed to receive the confirmable waitlist flow described here. Delivery audit records retain recipient/status metadata as described above, not message bodies.