.png)
Adobe Experience Manager Integration Guide
Integrate Adobe Experience Manager with enterprise systems through REST APIs, GraphQL, selected Adobe I/O Events, asset APIs, and governed Martini workflows.
Adobe Experience Manager integration options at a glance
Adobe Experience Manager supports REST and HTTP APIs for Assets, Sites content, Content Fragments, Cloud Manager, and related operations. Its GraphQL API is primarily intended for read-oriented delivery of Content Fragments through schemas and persisted queries. AEM as a Cloud Service can also participate in selected Adobe I/O Events, while asset ingestion and processing may be asynchronous. Martini can consume these APIs, receive supported event notifications through an exposed API, orchestrate scheduled reconciliation, transfer files and metadata, and map AEM JSON, GraphQL, and asset responses into downstream systems. OAuth 2.0 and environment-specific credentials can be stored in Martini configuration.
| Integration point | Supported by Adobe Experience Manager? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | AEM REST and HTTP APIs support Assets, Sites content management, Content Fragments, Cloud Manager, and other operational activities. The available surface depends on the AEM version and deployment model. | Martini can consume AEM REST APIs, configure environment-specific authentication, map JSON responses, and orchestrate downstream writes. |
| GraphQL APIs | Yes | AEM GraphQL provides read-oriented headless delivery of Content Fragments through schemas generated from Content Fragment Models and persisted queries. | Martini can call AEM GraphQL endpoints, validate query inputs, transform responses, and expose a governed API façade to consuming applications. |
| Webhooks / outbound callbacks | Limited | AEM as a Cloud Service and related Adobe services support selected event notifications through Adobe I/O Events; coverage is not universal for repository changes. | Martini can expose an HTTPS API or webhook workflow, validate event payloads, deduplicate notifications, retrieve current AEM state, and retry transient processing. |
| Bulk / async / batch APIs | Limited | Asset ingestion, asset processing, migration scenarios, and selected Cloud Manager operations may be asynchronous or bulk-oriented. | Martini can orchestrate job-oriented workflows, poll or reconcile status where the relevant API supports it, and control batch size and concurrency. |
| File / attachment APIs | Yes | AEM Assets APIs support binary asset upload and download, metadata updates, folder organization, and supported renditions or processed derivatives. | Martini can transfer files and metadata, transform asset attributes, separate upload from processing completion, and route large payloads through controlled workflows. |
| Authentication | Yes | OAuth 2.0 server-to-server authentication, Adobe identity credentials, product profiles, and API permissions are common for Adobe-hosted APIs. Other deployments may use Basic Authentication or service users. | Martini can store credentials and secrets by environment, attach bearer tokens, and apply endpoint-specific authentication and authorization configuration. |
| Database access | No | AEM is repository-based and direct access to its underlying database should not be assumed for integration purposes. | Martini should use supported AEM REST APIs, GraphQL, events, or exports rather than connecting directly to the AEM repository database. |
How Adobe Experience Manager exposes data and business events
Adobe Experience Manager REST APIs
AEM exposes REST and HTTP-oriented interfaces for Assets, Sites content management, Content Fragments, Cloud Manager, and other deployment-specific operations. REST is the primary mechanism for operational content and asset integration.
Martini implementation pattern
Martini implementation pattern: a Martini workflow authenticates to the appropriate author, publish, preview, or Cloud Manager endpoint, calls the required AEM resource, validates the response, maps the result, and invokes downstream systems or returns a controlled API response.
Implementation sequence
Adobe Experience Manager GraphQL APIs
AEM GraphQL is primarily designed for read-oriented headless delivery of Content Fragments. Schemas are derived from Content Fragment Models and persisted queries can provide stable query contracts on publish or preview environments.
Martini implementation pattern
Martini implementation pattern: expose a controlled Martini API, validate query parameters, invoke an AEM persisted GraphQL query, apply authorization, filtering, caching, or transformation rules, and return a stable response contract to consumers.
Implementation sequence
Adobe I/O Events
AEM as a Cloud Service and related Adobe services support selected event notifications through Adobe I/O Events. Event coverage and delivery behavior depend on the event provider and subscription.
Martini implementation pattern
Martini implementation pattern: expose an HTTPS endpoint for supported Adobe events, validate the notification, use an event identifier or resource key for deduplication, retrieve current AEM state, and update downstream systems. Scheduled reconciliation supplements event processing where coverage is incomplete.
Implementation sequence
AEM Assets file APIs
AEM Assets provides HTTP-based operations for binary assets, folders, metadata, and related resources. Upload completion and asset processing completion may be separate lifecycle states.
Martini implementation pattern
Martini implementation pattern: a workflow receives or retrieves a file, transfers it to the appropriate AEM Assets endpoint, maps metadata and folder paths, and monitors processing where required before distributing the asset or its rendition.
Implementation sequence
AEM bulk and asynchronous processing
Asset ingestion, migration, processing, and selected Cloud Manager operations may be asynchronous or bulk-oriented. Behavior is operation-specific rather than uniform across all AEM APIs.
Martini implementation pattern
Martini implementation pattern: split large work into bounded batches, submit supported jobs, persist job or resource identifiers, poll or reconcile status, and route completed and failed items separately. Martini can combine event processing with scheduled reconciliation.
Implementation sequence
Common Adobe Experience Manager integration patterns
Pattern 1: Synchronize AEM Assets with a product platform
When to use this pattern
Use this pattern when product media and metadata must move between AEM Assets and a commerce or product platform. It accommodates binary transfer, metadata mapping, folder paths, renditions, asynchronous processing, and bidirectional conflict rules.
Integration direction
Example Mapping
| Adobe Experience Manager Field | Canonical Field | Target Field |
|---|---|---|
| asset path | media.externalPath | media.path |
| dc:title | media.title | label |
| metadata.productSku | product.identifier | sku |
| rendition URL | media.deliveryUrl | imageUrl |
Martini implementation pattern
A scheduled or event-triggered Martini workflow retrieves the current Asset, follows pagination where needed, maps metadata and binary references, and upserts the target item. It records the AEM path and modification marker as an idempotency key, separates processing-pending assets, and retries transient Adobe or target failures.
Martini capabilities used
- workflows
- API consumption
- file handling
- data mapping
- business rules
- error handling
Pattern 2: Expose a governed Content Fragment API
When to use this pattern
Use this pattern when web, mobile, or partner consumers need a stable API contract over AEM headless content without coupling each consumer directly to AEM GraphQL.
Integration direction
Example Mapping
| Adobe Experience Manager Field | Canonical Field | Target Field |
|---|---|---|
| Content Fragment _path | content.id | id |
| Content Fragment model fields | content.attributes | attributes |
| _metadata.schema | content.type | type |
| fragment variation | content.localeVariant | variant |
Martini implementation pattern
Martini exposes a REST API, validates consumer parameters, calls an AEM persisted GraphQL query, and transforms the result into a stable response. It can apply authorization, filtering, caching, and business rules while keeping AEM publish or preview endpoints and credentials behind the façade.
Martini capabilities used
- API exposure
- API consumption
- GraphQL integration
- data transformation
- validation
- security configuration
Pattern 3: Process AEM event notifications
When to use this pattern
Use this pattern for selected AEM or Adobe I/O Events that should trigger indexing, downstream publication, search updates, or synchronization. Because event coverage is selective, pair it with reconciliation for completeness.
Integration direction
Example Mapping
| Adobe Experience Manager Field | Canonical Field | Target Field |
|---|---|---|
| event.id | event.externalId | processingKey |
| event.resource | content.resourcePath | sourcePath |
| event.type | content.changeType | operation |
| resource.lastModified | content.modifiedAt | updatedAt |
Martini implementation pattern
A Martini API receives the event, validates it, checks durable deduplication state, retrieves the current resource from AEM, and updates the target. A scheduled workflow reconciles changes by last-modified time or inventory so missed or unsupported events do not permanently create drift.
Martini capabilities used
- API exposure
- webhook or event consumption
- workflows
- deduplication
- scheduled synchronization
- retry handling
Pattern 4: Synchronize external product content to AEM
When to use this pattern
Use this pattern when SAP S/4HANA, Adobe Commerce, Shopify, or another source system owns product or campaign data and AEM owns the experience presentation.
Integration direction
Example Mapping
| Adobe Experience Manager Field | Canonical Field | Target Field |
|---|---|---|
| materialNumber | product.id | fragment.productId |
| shortDescription | product.description | fragment.description |
| salesStatus | product.lifecycleStatus | fragment.status |
| imageReference | product.mediaReference | asset.reference |
Martini implementation pattern
A scheduled Martini workflow retrieves changed source records, validates required fields, applies publication and locale rules, and updates Content Fragments or Assets through AEM APIs. It records source versions, handles schema validation failures separately from transient API errors, and supports replay of rejected items.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- schema validation
- business rules
- audit and error handling
Applications commonly integrated with Adobe Experience Manager
Adobe Experience Manager commonly participates in composable digital experience architectures. The exact integration scope depends on the AEM deployment, Adobe products in use, and the APIs exposed by each adjacent application.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Adobe Commerce | Exchange product, catalog, media, and campaign content across commerce and experience channels. | Adobe Commerce → Martini → Adobe Experience Manager | Martini can schedule or receive changes from Adobe Commerce, map product and media data to AEM Content Fragments or Assets, and apply idempotent upsert and retry rules. |
| Salesforce | Coordinate customer, campaign, personalization-related content, and audience context with AEM-managed digital experiences. | Salesforce → Martini → Adobe Experience Manager | Martini can consume Salesforce APIs, validate selected experience data, transform it into AEM-compatible structures, and route content or context updates through AEM APIs. |
| SAP S/4HANA | Publish product, pricing, material, and business master data into AEM-managed web experiences. | SAP S/4HANA → Martini → Adobe Experience Manager | A scheduled Martini workflow can retrieve approved SAP data, normalize identifiers and attributes, update AEM Content Fragments or Assets, and record rejected or transient changes for replay. |
| Shopify | Combine Shopify commerce data with AEM-managed content, media, and presentation experiences. | Shopify → Martini → Adobe Experience Manager | Martini can retrieve selected Shopify product data, map it to AEM content models, and coordinate outbound content or asset references for storefront delivery without coupling systems directly. |
| Workday | Publish recruiting, corporate, or employee-facing content while sourcing selected organizational data from Workday. | Workday → Martini → Adobe Experience Manager | Martini can schedule Workday API retrievals, validate organizational fields, transform approved data into AEM content structures, and isolate environment-specific author and publish endpoints. |
| ServiceNow | Publish support, knowledge, or service experience content through AEM-managed digital channels. | ServiceNow → Martini → Adobe Experience Manager | Martini can consume ServiceNow and AEM APIs, map knowledge or service content, apply publication rules, and synchronize status with durable error handling. |
| Jira | Connect editorial, development, campaign, and release workflow metadata with AEM content delivery processes. | Jira → Martini → Adobe Experience Manager | Martini can exchange selected issue and content workflow metadata, apply routing rules, and expose a stable API for downstream status updates. |
| Adobe Analytics | Combine AEM-delivered experience context with behavioral analytics and measurement workflows. | Adobe Experience Manager → Martini → Adobe Analytics | Martini can orchestrate approved content or event metadata flows between AEM-related endpoints and Adobe analytics APIs, applying filtering and transformation rules. |
How to build a Adobe Experience Manager integration in Martini
Objective
Establish environment-specific access to AEM author, publish, preview, Assets, GraphQL, or Cloud Manager endpoints without embedding credentials in workflow logic.
Instructions in Martini
- Select OAuth 2.0 server-to-server credentials where supported for the deployment
- Store client credentials, tokens, and endpoint settings in Martini configuration and secrets
- Scope Adobe product profiles, AEM permissions, service users, and repository paths to the integration
- Keep author, publish, preview, and administration endpoints separate
Objective
Select an event-driven, API-led, or scheduled start based on the completeness and latency requirements of the AEM process.
Instructions in Martini
- Use a Martini API or webhook workflow for supported Adobe I/O Events
- Use a scheduler for reconciliation, inventory, and periodic synchronization
- Use an exposed API when downstream applications need a governed AEM façade
- Document whether the source operation is synchronous, asynchronous, or job-based
Objective
Obtain the relevant AEM resource, event context, file, or GraphQL response while handling pagination and environment-specific behavior.
Instructions in Martini
- Call the appropriate AEM REST, GraphQL, or Assets API
- Use persisted GraphQL queries for governed Content Fragment delivery where available
- Follow continuation links, cursors, offsets, or API-specific pagination fields
- Retrieve current resource state after an event rather than relying only on event payloads
Objective
Coordinate AEM calls, downstream applications, asynchronous processing, and reconciliation as a maintainable Martini workflow.
Instructions in Martini
- Separate validation, retrieval, transformation, target writes, and status recording
- Branch between completed, processing-pending, rejected, and transient-failure states
- Persist event identifiers, resource paths, versions, or modification timestamps
- Use bounded concurrency and batch sizes for large asset or content workloads
Objective
Convert AEM JSON, GraphQL, asset metadata, and binary references into canonical and target-specific structures.
Instructions in Martini
- Map Content Fragment Model fields to a versioned internal contract
- Normalize paths, identifiers, locales, metadata, and rendition references
- Stream or bound large file handling where supported
- Validate required fields and isolate schema or model mismatches
Objective
Apply publication, authorization, deduplication, conflict, and routing decisions before writing to target systems.
Instructions in Martini
- Distinguish author, publish, and preview use cases
- Apply source-of-truth and conflict rules for bidirectional synchronization
- Use deterministic idempotency keys for events and resource updates
- Prevent publication of incomplete or unauthorized content
Common Adobe Experience Manager data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Assets | Images, videos, documents, PDFs, creative files, metadata, and processed renditions. | Adobe Commerce, Shopify, product platforms, search platforms, and downstream DAMs | Martini transfers binaries or references, maps metadata, manages folder paths, and accounts for asynchronous processing and idempotent updates. |
| Content Fragments | Structured reusable content delivered to websites, applications, mobile channels, and other consumers. | Web applications, mobile platforms, commerce platforms, and personalization services | Martini consumes Content Fragment data through REST or GraphQL, validates model fields, transforms contracts, and routes approved changes. |
| Pages | Hierarchical Sites content containing page properties and component content. | Websites, search platforms, analytics processes, and publishing workflows | Martini retrieves or updates supported page resources, separates author and publish environments, and applies publication and reconciliation rules. |
| Experience Fragments | Reusable presentation-oriented content blocks shared across pages or channels. | Web channels, commerce experiences, campaign platforms, and personalization solutions | Martini maps fragment metadata and references, applies channel-specific rules, and synchronizes approved content through AEM APIs. |
| Folders | Repository and Assets structures used to organize pages, assets, and resources. | DAMs, product platforms, migration stores, and content governance systems | Martini preserves or translates folder paths, validates permissions, and uses paginated retrieval for large structures. |
| Content Fragment Models | Schemas defining the fields and structure of Content Fragments. | Headless applications, API façades, content validation services, and downstream data models | Martini treats model changes as contract changes, validates payloads, and maintains version-aware mappings and regression tests. |
Authentication and security considerations
Authentication and access control
Adobe Experience Manager as a Cloud Service commonly uses OAuth 2.0 server-to-server authentication with Adobe Developer Console credentials and bearer tokens. Product profiles, API scopes, AEM permissions, service users, and repository paths determine what the integration can access.
On-premises and Adobe Managed Services deployments may also use Basic Authentication, AEM users and groups, service users, reverse proxies, or enterprise identity layers. Martini should store credentials in environment-specific secrets and keep author, publish, preview, and administration endpoints separate.
- Prefer OAuth-based authentication for new supported integrations.
- Scope permissions to required Assets, Content Fragments, Pages, folders, and Cloud Manager operations.
- Protect exposed Martini APIs with authentication and authorization controls.
- Do not place client secrets or tokens in workflow mappings or payloads.
Operational considerations for Adobe Experience Manager integrations
Design for AEM operating characteristics
AEM APIs can paginate results, impose throughput or concurrency limits, and return asynchronous processing states. Asset upload completion may occur before metadata extraction or renditions are available.
- Follow API-specific pagination and continuation fields.
- Use bounded concurrency, batch sizes, and backoff for 429 and transient 5xx responses.
- Use event identifiers, resource paths, versions, or modification timestamps for idempotency.
- Separate transient failures from authorization, validation, path, and schema errors.
- Test author, publish, preview, Dispatcher, CDN, and cache behavior separately.
- Treat Content Fragment Model changes as contract changes requiring mapping and regression tests.
- Use scheduled reconciliation because selected Adobe events do not cover every AEM mutation.
- Stream or bound large binary transfers where supported and verify deployment-specific limits.
Why use Martini instead of scripts or point-to-point integrations?
Orchestration instead of isolated scripts
Martini provides a maintained integration layer for AEM APIs, GraphQL queries, event notifications, files, and downstream applications. Workflows make retrieval, transformation, business rules, target writes, and reconciliation explicit rather than scattering behavior across scripts.
- Centralize environment configuration, OAuth credentials, and secrets.
- Reuse mappings and workflow logic across author, publish, preview, and production environments.
- Combine real-time event processing with scheduled synchronization and reconciliation.
- Expose stable APIs that shield consumers from AEM endpoint and schema changes.
- Apply consistent validation, retries, deduplication, logging, and operational error handling.
- Extend workflows with custom logic only where the standard integration flow requires it.
Frequently asked questions
Adobe Experience Manager can integrate through REST and HTTP APIs for Assets, Sites content, Content Fragments, and Cloud Manager; GraphQL for read-oriented Content Fragment delivery; file and asset APIs; selected Adobe I/O Events; and scheduled synchronization. The exact API surface depends on the AEM version and deployment model.
Yes. Martini can consume Adobe Experience Manager REST and GraphQL APIs, transfer asset files and metadata, receive supported Adobe I/O Events through an exposed API, run scheduled reconciliation workflows, and transform AEM data for downstream applications.
No. A dedicated Adobe Experience Manager connector is not required. Martini can use AEM's confirmed native REST, GraphQL, Assets, authentication, and selected event mechanisms through standards-based API consumption, API exposure, workflows, and data transformation.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Adobe Experience Manager. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Adobe, cloud infrastructure, or other third-party systems based on subscription, usage, and deployment model.
Use REST for management and operational activities such as asset updates, content administration, and supported Cloud Manager operations. Use GraphQL primarily for read-oriented headless delivery of Content Fragments through schemas and persisted queries.
Selected AEM and Adobe service event notifications are available through Adobe I/O Events, but they do not represent a universal webhook for every repository mutation. Martini can receive supported events through an HTTPS API and supplement them with scheduled reconciliation.
Martini can combine event-driven workflows with scheduled reconciliation using event identifiers, resource paths, versions, or modification timestamps. Durable processing state, idempotent upserts, pagination, and bounded retries help prevent duplicate processing and recover from missed notifications.
Yes. Martini can expose a controlled REST API that validates requests, calls AEM REST or GraphQL endpoints, applies authorization and business rules, transforms responses, and returns a stable contract to web, mobile, partner, or internal applications.
Related Martini documentation
Workflows
Transformation
Build a maintainable Adobe Experience Manager integration
Use Martini to connect Adobe Experience Manager APIs, selected Adobe events, asset workflows, and downstream enterprise systems with secure configuration, reusable mappings, orchestration, and operational controls.