The full picture, in one page

The six destination types

Every destination belongs to one of these types. Some are gated by plan; the in-app inbox is universal.

Per-type override (the routing rule)

Per-type override is how otp1 decides which destinations fire for a given email. The same rule applies independently to each destination type, so a catch-all Discord and a source-specific Slack can both fire for the same email.

• Each destination type is evaluated independently against the triggering source.
• If you have any active source-specific destination of type T, only those fire for that source. The catch-all of type T is skipped.
• Otherwise, the active catch-all destinations of type T fire.
• A paused destination of type T is treated as absent — the catch-all of type T fires in its place.
• Within the winning scope, every active destination fires. Two catch-all email links → two links, not one.
• No OTP extracted → no deliveries fire for any type.
• Shares are exempt from this rule — they are always source-specific and follow their own fan-out logic.

Reliability

• Retries. Failures retry with exponential backoff: 1 minute, 5 minutes, 25 minutes. Three attempts total.
• Circuit-breaker. Three consecutive permanent failures (HTTP 4xx that aren\u2019t 408/429) put the destination behind a 24-hour circuit-breaker. No further deliveries attempt until it resets.
• Per-attempt timeouts. 5 seconds to connect, 10 seconds total. A hung destination cannot stall the worker.
• Error visibility. Permanent failures are surfaced in the UI as a delivery-error row with the response snippet and a "retry" path.

The four-step lifecycle

1. 1

   Sharer — Creates an invite

   You pick a source, type the recipient’s email (they must be an otp1 user, or sign up via the invite link), and optionally enter a from-filter. The API validates the pattern and creates a pending share_request. The recipient is sent a one-shot invite email disclosing the filter, if any.

2. 2

   Recipient — Accepts (or rejects) the invite

   Pending invites show up in the recipient’s in-app inbox as a banner with Accept / Reject buttons. There is no email-based accept link — it is in-app only. Rejecting is a hard-delete of the pending row; you can be re-invited immediately. Accepting creates an active source_share row.

3. 3

   Both sides — OTPs flow automatically

   For every email processed on the sharer’s source, the pipeline evaluates each active source_share on that source. If the share has no filter, it always matches. If it has a from-filter, the From: address must match the pattern. Each matching share gets its own shared_emails row in the recipient’s inbox, with a real-time SSE push.

4. 4

   Recipient — Revokes (or sharer revokes)

   The recipient can revoke an active share at any time. Revocation is a hard-delete of the source_share row, which cascades the shared_emails rows. There is no re-share on the recipient side: shares are leaves in the trust tree.

Caps

Two independent per-sharer caps. The pending cap is uniform across plans; the active cap scales with the plan.

From-filter: share only OTPs from a specific sender

A share is, by default, an unfiltered "share all OTPs from this source" binding. The from-filter lets the sharer narrow that to a specific From: address or domain, so the recipient sees only the OTPs the sharer wants them to see.

Pattern format

One string per share. Detection is by the presence of @:

• A value with an @ sign is treated as an exact-email pattern (e.g. noreply@incometax.gov.in).
• A value with no @ sign is treated as a bare-domain pattern (e.g. incometax.gov.in).
• Exact-email match is case-insensitive equality on the full From: address after both sides are lowercased and trimmed.
• Domain match is case-insensitive equality on the domain part of the From: address. Subdomains do not match — incometax.gov.in matches noreply@incometax.gov.in but not noreply@mail.incometax.gov.in.
• Empty or malformed From: addresses silently fail to match filtered shares. Share-all shares still match.
• No wildcards, no regex, no multiple addresses per share, no subject matching. One pattern per share.
• The pattern is immutable after creation. To change it, the sharer revokes the share and creates a new one with a different pattern.
• The recipient can see the from-filter value on every matched inbox row and in the detail view. They cannot see which OTPs were filtered out — only the scope this share matches.