Consent, unsubscribe and preferences

​

Two kinds of email

​

Rules in a workspace that sends for tenants

• A marketing template only goes to an existing contact with email marketing consent. An unknown address or a contact without consent is refused: nothing is sent, no contact is created, and the send answers 422 MARKETING_CONSENT_REQUIRED. Add the guest with marketingConsent first (or with the booking event, see below). Utility templates are not affected.
• Every marketing email of a restaurant carries the unsubscribe footer and the one-click List-Unsubscribe header. Withdrawals are recorded by Minimo, on the same page and endpoint for every restaurant.
• In the editor a restaurant cannot remove the footer, hide the sender identity line or replace the email with HTML that drops the unsubscribe link (422 TENANT_FOOTER_REQUIRED).
• The automatic rules check consent again when a marketing email is due: a guest who unsubscribed in the meantime is skipped (no_marketing_consent).

​

Consent per workspace or per restaurant

​

Consent per restaurant

• Who receives a restaurant’s marketing email (campaign, marketing template such as the review request, automatic message with a marketing template): only guests subscribed to that restaurant, with evidence of their consent, and who have not unsubscribed from your workspace. Everyone else is skipped, at send time and again when a scheduled email fires. A 1:1 send to a guest who is not subscribed answers 422 TENANT_SUBSCRIPTION_REQUIRED. Utility emails are never affected.
• How a subscription is recorded: when a restaurant adds a guest in the Campaigns widget with the consent box ticked; when your booking event on POST /public/v1/events carries tenant and marketingConsent: true (put the details in payload.consentEvidence); or with the subscriptions API below. Recording a consent for one restaurant never changes what the guest agreed with another one.
• Unsubscribe: the link and the mailbox unsubscribe button of a restaurant’s email stop that restaurant only. The page names the restaurant, shows the data controller and offers to also unsubscribe from every email sent through your SaaS, which stops every restaurant. The preferences page lists the restaurants the guest is subscribed to and lets them leave one.
• Spam complaints stop marketing from your whole workspace for that guest, and count against the restaurant (see protections).
• After an unsubscribe, a guest can be subscribed again only with a consent given later than the unsubscribe (evidence.consentedAt). The widget never subscribes them again.

​

Subscriptions API

{
  "subscriptions": [
    {
      "email": "giulia@example.com",
      "status": "subscribed",
      "source": "booking",
      "evidence": {
        "ref": "booking-4812",
        "consentText": "Voglio ricevere offerte da Trattoria da Mario",
        "consentVersion": "booking-form-v3",
        "ip": "203.0.113.7",
        "userAgent": "Mozilla/5.0 ...",
        "consentedAt": "2026-11-08T19:30:00+01:00"
      }
    },
    { "email": "marco@example.com", "status": "unsubscribed", "reason": "Unticked in the booking form" }
  ]
}

​

The pages guests see

• For a restaurant’s email it shows the restaurant’s name, logo and color (from the tenant profile) and its data controller, never your SaaS’s branding.
• The guest confirms on the page and can pick a reason. The unsubscribe button of the mailbox (the List-Unsubscribe header) works without the page. There is no one-click “subscribe again” on the success page.
• The preferences page shows who can write to the guest first, then the channels, and hides contact fields that are empty.