DocumentationExperience Cloud KCS

Resolving PDF Embed API domain authorization failures in AEM

Last update: June 27, 2026

The AEM PDF Viewer and custom components using the Adobe PDF Embed API fail with a domain authorization error when the domain hosting the page isn’t registered in Adobe Developer Console for the associated PDF Embed API Client ID. The PDF Embed API allows only one domain per Client ID and rejects requests from unregistered origins, so each AEM domain — Author, Publish, and custom DNS — needs its own Client ID. AEMaaCS also requires Sling Context-Aware Configuration (CaConfig) for the PDF Viewer rather than an OSGi config, which otherwise resolves the wrong Client ID. Creating per-domain Client IDs and configuring them in the correct CaConfig path restores the viewer.

Description description

Environments:

  • Adobe Experience Manager as a Cloud Service (AEMaaCS)
  • AEM Brand Portal
  • AEM Managed Services
  • AEM Core Components PDF Viewer and the Adobe PDF Embed API

Issue/Symptoms:

  • The PDF Viewer displays This application domain (< domain> ) is not authorized to use the provided PDF Embed API Client ID.
  • The PDF preview shows File preview not available with error code UnauthorizedDomainForClientId.
  • The PDF Viewer loads but renders nothing, and the browser network panel shows blocked viewer API calls with a domain mismatch.
  • The Adobe Developer Console project shows This project is read only because it was auto-generated by Adobe and can’t be edited.

Root cause:

The Adobe PDF Embed API allows only one domain per Client ID (unless using subdomains under a single root) and rejects any request from an unregistered origin. AEMaaCS environments — Author, Publish, custom domains, and Dev/Stage/Prod — each use different domains, so they require separate Client IDs and separate CaConfig configurations. AEMaaCS doesn’t support PDF Viewer configuration via OSGi; using OSGi leads to incorrect clientId resolution and viewer failures.

How to confirm

  1. Identify the failing domain. Open the page with the PDF Viewer and note the full browser origin (for an AEMaaCS host this looks like https://author-pXXXXX-eYYYYYY.adobeaemcloud.com; for a custom domain it’s your site’s origin). Run window.location.origin in the browser console to confirm the exact string.
  2. Verify whether the Developer Console project is editable. Open the project containing the PDF Embed API credential and look for the banner This project is read only because it was auto-generated by Adobe, which indicates you need a new editable project.

Resolution resolution

  1. If the project is read-only, create a new editable project. In Developer Console, choose Create new project → Add to project → PDF Embed API, which exposes an editable Application Domains section. If you can’t add a domain, confirm you hold the System Admin and Developer roles.
  2. Register the domain that matches the failing origin. In the PDF Embed API setup, add the exact domain only, without the https:// prefix (for example: example.com or author-pXXXXX-eYYYYYY.adobeaemcloud.com). Save the configuration and reload the page in an incognito window.
  3. Create separate Client IDs per environment or domain. Repeat the domain registration for each environment (Author, Publish, custom DNS), since AEMaaCS requires unique Client IDs when domains differ. If you need many subdomains, create one credential using the parent domain only.
  4. Configure the Client ID in AEM using Sling Context-Aware Configuration. In your codebase under /conf/<site>/sling:configs, create the node com.adobe.cq.wcm.core.components.internal.services.pdfviewer.PdfViewerCaConfig with the property clientId = < Client ID>. Confirm in CRXDE that the property exists, and that your site’s jcr:content includes a sling:configRef.
  5. For Author and Publish, create runmode-specific configs when needed. Create /conf/<site>/sling:configs.author and /conf/<site>/sling:configs.publish, each containing its own clientId, so Author uses the author config and Publish uses the publish config. Confirm by viewing the page source on each environment and searching for the clientId string.
  6. Remove any OSGi configuration for the PDF Viewer. Delete com.adobe.cq.wcm.core.components.internal.services.pdfviewer.PdfViewerCaConfig.cfg.json from ui.config so only CaConfig drives the viewer settings, then confirm in /system/console/configMgr that no OSGi config exists.
  7. Deploy via Cloud Manager. Run your pipeline and confirm the /conf changes reach both Author and Publish by opening CRXDE on each. If the changes don’t appear, confirm your pipeline includes the ui.content module.

Validation

  1. Open the page over each domain (Author, Publish, DNS) and confirm the PDF renders without the authorization error.
  2. Inspect the page source and confirm the expected clientId is embedded and matches the CaConfig value.
  3. Use the browser Network panel to confirm the viewer API calls return HTTP 200 rather than domain-authorization failures.
recommendation-more-help
experience-cloud-kcs-help-kbarticles