> ## Documentation Index
> Fetch the complete documentation index at: https://help.lobyco.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Consent

> Consent types, versioning and how acceptance is tracked across customer and device scope.

Loyalty runs on customer data, so a customer has to consent before you can process it. Consent is a single source of truth across every Lobyco service — accept once in the app, and the answer is visible everywhere.

The service exists to keep you compliant: it tracks acceptance of terms and privacy policies for GDPR and similar regimes, manages marketing opt-ins per channel, versions each document, serves localised content, and keeps a full audit trail of every acceptance and withdrawal.

## Two kinds of consent

```mermaid theme={"system"}
flowchart TD
    C["Consent"] --> M["Customer scope<br/>shared across devices"]
    C --> D["Device scope<br/>local to one device"]
    M --> N["Necessary"]
    M --> O["Optional"]
```

|                | Customer scope                                               | Device scope                                         |
| -------------- | ------------------------------------------------------------ | ---------------------------------------------------- |
| Covers         | Data shared across mobile, web and backend services          | Data handled locally, or exposed to third-party SDKs |
| Given          | Once, at sign-up — including when membership starts in store | Per device                                           |
| Applies to     | Every device the customer uses                               | Only the device it was given on                      |
| Implemented by | The consent service                                          | The **Data Privacy Manager** component on mobile     |

### Customer consents

**Necessary** consents are requested during sign-up and are mandatory — the customer cannot finish registering without them. They cover the data processing the products fundamentally depend on, such as membership itself and email from the preferred store.

**Optional** consents unlock extra product-specific functionality. Some can be switched off again; some cannot.

| Can be toggled later      | Cannot be turned off once enabled               |
| ------------------------- | ----------------------------------------------- |
| CO2 footprint calculation | Prime subscription handling                     |
| Email communication       | Scan\&Pay terms of use                          |
| Push notifications        | Marketing data for Facebook and other marketers |

### Device consents

These break down into consents for sharing data with third parties, for accessing device and OS data, and for advertisement.

On mobile they run through the Data Privacy Manager, which sets a privacy level on the device. Third-party SDKs then decide what user-identifiable data they may access based on that level.

## Agreements versus opt-ins

Every consent has a type, and the type decides whether a customer can change their mind.

| Type        | Behaviour                             | Example               |
| ----------- | ------------------------------------- | --------------------- |
| `Agreement` | Must be accepted, cannot be withdrawn | Terms & Conditions    |
| `OptIn`     | Can be opted into and out of freely   | Marketing preferences |

<Warning>
  Once a customer accepts a specific version of an agreement, **neither the customer nor an admin can set it back to not accepted**. Design your support flows around that.
</Warning>

## Versioning

Consents are versioned so you can change the wording without silently re-interpreting an old acceptance.

| Change                     | Effect on customers                            |
| -------------------------- | ---------------------------------------------- |
| **Version** (v1 → v2)      | Major change. Customers must accept again.     |
| **Revision** (v1.0 → v1.1) | Minor change. Existing acceptances carry over. |

When a new *version* of the terms is published, customers get a popup on next use telling them the terms have changed and asking them to accept before continuing. This is what makes the Terms & Conditions flow work: the customer reads them at sign-up, or later from **Profile → Permissions → Terms & Conditions**.

Other consents are managed by the customer at **Profile → Permissions**.

<Info>
  Consents are **soft-deleted**. Deactivating one keeps the historical record, so a past acceptance is never lost.
</Info>

## What is recorded

Each consent carries a unique **key** (for example `terms_and_conditions`, `marketing_consent`), its version and revision, its type, active and expiry dates, publish status, and localised name and content per language.

Against that, each customer's record captures:

* **Acceptance** — when and how it was given
* **Withdrawal** — when and how it was withdrawn, for `OptIn` types
* **Activation source** — the channel it came through, such as `WEB`, `MOAPP` or `EMAIL`
* **Metadata** — IP address, user agent, campaign information and similar audit context

Rejection is tracked distinctly from silence, so an explicit "no" is distinguishable from never having been asked. Reactivation is supported — a customer can accept, withdraw and accept again — and optimistic concurrency control prevents two conflicting writes from racing.

Single and bulk activation and withdrawal are both available, and consents can be queried by key, ID, status or type, including a query for exactly those consents still awaiting a customer's acceptance.

Admins create, edit and version consents in the Admin Tool, with a rich text editor, multi-language content and bulk import and export.

## API reference

Endpoint documentation: [Consent](/api-reference/loyalty-and-membership/consent).