At work
Transket · Jul 2025 – Present
Consent on the inbound path
Consent as a regulatory gate on inbound messages: per-type records, cache-first lookup, and a deferred-intent replay after the user opts in.
The problem
Inbound traffic is the wrong place to discover that you never stored consent properly. A single true/false flag also cannot express different consent types, and a user who messages you before opting in should not lose that intent forever.
What it is
A denormalized boolean cannot represent WhatsApp-style consent. I rebuilt opt-in as a first-class check on the inbound path, and solved the message that arrives before consent with a deferred-intent pattern instead of dropping it.
What I built
Consent is a per-type record, not a column on the contact. The inbound path treats it as a gate: if the type of traffic is not allowed, the message does not proceed into workflow execution.
Lookups are cache-first so the gate stays cheap under volume, with the durable record remaining the thing you would trust in an audit.
When a user writes in before they have opted in, the original intent is stored and replayed after consent is granted. That closed a class of silent message loss: the product no longer has to pretend the first message never happened.
How it fails
Missing or expired consent fails closed. Cache misses fall back to the record; they do not invent permission. Replay happens only after a real opt-in event, so a cached “maybe” cannot become a send.
Focus
- Per-type consent instead of a denormalized boolean
- Cache-first lookup on the inbound hot path
- Deferred intent that replays after opt-in
What changed
- Inbound handling matches how regulators think about consent, not how a CRM boolean does.
- Users who message before opt-in are not asked to start over.