APPLICATION CONSENT SCREEN
Choose what people see before they subscribe.
In Company → Sites & apps, open your application and choose Consent screen. Applications such as MuMaps begin with the choices already configured in their signed consent manifest.
- Edit the content. Give every email option a clear title, description and frequency. Keep existing purpose IDs when the meaning stays the same. Add a new option for a different purpose. Choose Optional or Required in each option. Optional choices start unchecked; required choices are included when the visitor submits, with cancellation still available. Supply your privacy policy and optional terms URL.
- Match your brand. Choose Get design from my website to suggest a logo and colors from your connected website or another public HTTPS page on its exact verified domain. Review the proposal and select what to import, then choose Apply to draft. This changes only your local appearance until you save and publish. External assets and unverified subdomains are skipped. If the site cannot be read, set your logo and colors manually. Upload a PNG, JPG or WebP logo (up to 5 MB). Emabled resizes it to PNG. Choose separate page, card, text, button and accent colors. Dark website backgrounds stay dark; accents can outline buttons without becoming their fill.
- Check the live preview. Switch between desktop and mobile. Optional choices start unchecked. Preview buttons do not submit a decision.
- Save draft. This keeps your changes for later. It does not change what people currently see.
- Publish consent screen. Review the confirmation. New consent sessions that use the published screen receive this version. Existing sessions, choices and receipts keep their original version.
The Save and publish panel keeps your next step, status messages, buttons and confirmations together. While a website design is only a proposal, apply it first. After an edit, save the draft before publishing. If a button is unavailable, the panel explains what is needed, including missing content or a draft that is already published.
Connect your site to sign consent changes
- Ask the developer who manages your site to add the signing handler described below to an HTTPS endpoint on your backend. Your application’s private key stays on that server.
- In the console, open your site in Company → Sites & apps → Setup. Open All integration tools → Manage exchange endpoints (or choose Connect signing endpoint directly from your saved consent screen) to register the URL and complete its verification challenge.
- Return to Consent screen and choose Check publishing status. When your draft is ready, choose Publish consent screen and confirm.
Branding-only updates can reuse your existing signed consent text. Your site signs new wording and choices so visitors and email providers can verify which permissions your company requested.
Your application backend keeps its private signing key. Text changes need a new XCIM consent manifest signed by that backend. Emabled sends a short-lived, issuer-signed request to the exchange endpoint already verified for the application. The updated .NET reference backend handles this request automatically; never paste a private key or OAuth client secret into the editor.
In the reference backend, enable Vendor:UsePublishedConsentScreen=true. When using the .NET SDK directly, set UsePublishedConsentScreen: true in the create-session request. Direct HTTP integrations send use_published_consent_screen: true to POST /v1/consent-sessions. Store the returned resolved_manifest_id with the flow and validate its receipt against that manifest. The configured manifest remains the fallback until the first publication.
Integrations that omit this flag keep their configured consent text. Appearance-only publications can reuse that text. If text publication reports that your backend could not sign, your saved draft and currently published screen remain available. Update the backend handler and retry the same saved publication.
Backend signing contract
The existing verified exchange endpoint accepts application/emabled-consent-screen-sign-request+jcs. Verify the flattened JWS against the pinned Emabled issuer key, the protected key ID, application ID, epoch, application key ID, endpoint URI, manifest commitment and one-minute lifetime. Reject unknown fields and invalid manifests. Sign only the validated unsigned manifest using the existing consent-manifest signing domain. Return the canonical signed manifest as application/xcim-consent-manifest+json. The API verifies the company signature before activation.
Permissions and recovery
Editing and publishing require a workspace owner or admin with MFA verified. A draft changed in another tab must be refreshed before saving. If a response is lost, refresh saved status before retrying; opening this page never publishes automatically. Published versions are listed below the editor.
Publishing changes the consent request shown to future visitors. It does not grant or expand permission for existing subscribers or an ESP.