molted consent

Command	Description
`molted consent record`	Record a consent decision for a recipient
`molted consent check`	Check consent status for an email address

Agent context

Consent manages the legal basis for contacting each recipient. By default consent is just a ledger: recording it here does not by itself stop any send. A tenant can opt into enforcement with
molted settings update --require-consent-for-marketing true (default false) -- once that is on, a MARKETING template send to a recipient without active consent is blocked with reason "no_consent". Transactional emails (receipts, password resets) are always exempt, whatever the setting.

molted consent record --email alice@example.com \
  --type explicit_opt_in --source signup-form --jurisdiction EU
# → records that alice explicitly opted in via signup form in the EU

molted consent record --email bob@example.com \
  --type legitimate_interest --source existing-customer --jurisdiction US-CA

molted consent record --email alice@example.com \
  --type explicit_opt_in --revoked-at 2025-06-15T00:00:00Z
# → appends a withdrawal; with enforcement on, marketing sends to alice
#   are blocked from now on (any revokedAt counts at once, even a future one)

molted consent check --email alice@example.com
# → { "hasConsent": true, "basis": "explicit_opt_in", "source": "signup-form",
#     "jurisdiction": "EU", "grantedAt": "..." }
# → { "hasConsent": false } (or with "revokedAt" after a withdrawal): do not send marketing email

Consent types (legal basis):

explicit_opt_in - recipient explicitly agreed (strongest basis)
legitimate_interest - business relationship justifies contact
contractual - required to fulfill a contract
legal_obligation - legally required communication

Any basis counts as active consent for enforcement; the basis is recorded, not ranked.

Jurisdictions: free-form (e.g. "EU", "US-CA", "UK", "BR") - recorded for your own compliance records, never used for enforcement.

Key behaviors

Consent is per-email, not per-contact; records are append-only and the latest record for an email (matched case-insensitively) decides
--granted-at defaults to now, except on a withdrawal-only record
Enforcement is opt-in and off by default (settings get shows the current value)
When enforced, marketing templates require consent; transactional templates never do, and list broadcasts are exempt (the list subscription is the consent)
Recording a withdrawal (--revoked-at) also works with a mailbox-scoped key that can send from at least one mailbox; granting consent needs a workspace key (admin, or all mailboxes) with write scope
consent check is useful for pre-flight validation in your agent logic, whether or not enforcement is on

Commands

Record a consent decision for a recipient

molted consent record [options]

Option	Description	Default
`--email <email>`	Recipient email address (required) (required)
`--type <basis>`	Consent basis (required; one of: explicit_opt_in, legitimate_interest, contractual, legal_obligation)
`--source <source>`	Source of the consent (e.g. signup-form)
`--jurisdiction <code>`	Jurisdiction (e.g. EU, US-CA)
`--granted-at <iso>`	When consent was granted (ISO 8601, default now)
`--revoked-at <iso>`	When consent was revoked (ISO 8601); makes this record a withdrawal

Check consent status for an email address

molted consent check [options]

Option	Description	Default
`--email <email>`	Email address to check (required) (required)

See CLI overview for global options, credentials and output format.

On this page