Component Overview

Mas Consents is a hosted frontend that lets a customer review and submit consent statements. It is intended for customer-facing flows where an application needs to show, collect, or update consents without implementing the consent UI itself.

Consumer applications embed the component and build its URL with the customer context, authentication token and business flow to load. The component then talks to the Consents backend, renders the consent statements and reports the result back to the host application.

What the component provides

Mas Consents provides:

a hosted consent UI ready to be embedded in iframe, popup or WebView flows
loading and submit calls against the Consents backend
locale handling for the supported languages
lifecycle messages for loaded, completed and error states
optional visual and behavior customization through JSON configuration

Basic integration contract

The host application provides the runtime context. Mas Consents owns the consent UI and the calls needed by the embedded flow.

Area	Host provides	Component handles
Authentication	A token scoped for the embedded consent flow	Sends the token to the Consents backend as bearer authentication
Customer context	`customerId`, `brand` and `sector` URL parameters	Uses them to load and submit the correct consents
Flow selection	One or more `view` values, and optionally `choice`	Requests the consent set for that flow
Localization	`lang`, and optionally `locales`	Selects the initial language and available languages
Result handling	Listeners for completion and error messages	Emits lifecycle messages to the host
Customization	Optional JSON configuration when requested	Applies the received theme, UI options and token overrides

Integration model

text

Host application
  -> builds the iframe / WebView URL
  -> optionally listens for CONSENTS_CONFIG_REQUIRED
  -> optionally sends SET_CONFIG
  -> listens for loaded, completed and error events

mas-consents
  -> reads URL parameters
  -> loads /config.json
  -> initializes the bridge
  -> renders the Custom UI path
  -> calls the backend
  -> reports lifecycle events back to the host

Host responsibilities

The host application must:

provide the URL parameters needed by the target flow
provide a token valid for the embedded consent flow
listen to completion and error events
decide what to do after the customer submits or the component reports an error
send JSON configuration only when it wants to customize the component

The host application does not need to understand the internal statement tree, Consents backend implementation, or local development setup to integrate the component. Those details are covered in the IDP technical reference.

Runtime behavior

The runtime has one rendering path: AppCustomTheme mounting ConsentsCoreCustom. The previous Legacy UI component is no longer part of the application flow.

enableCustomConfig does not select a different component implementation. It only controls whether the component renders immediately with defaults or waits for a SET_CONFIG message before rendering.