.png)
Akeneo Integration Guide
Connect Akeneo Product Cloud with enterprise applications through REST APIs, selected webhook events, catalog processing jobs, and secure OAuth 2.0 authentication.
Akeneo integration options at a glance
Akeneo’s primary integration mechanism is its REST API, which supports catalog resources such as Products, Product models, Categories, Families, Attributes, and Channels. The API provides collection queries, pagination, filtering, partial updates, media operations, and job-related import and export processing. Akeneo also provides webhook-style notifications for selected events and editions, although coverage is not universal. OAuth 2.0 bearer tokens secure API access. Martini can consume these APIs, receive supported notifications through a REST API endpoint, process files, orchestrate jobs, map localized and channel-specific data, and combine event-driven processing with scheduled reconciliation for reliable synchronization.
| Integration point | Supported by Akeneo? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Akeneo’s principal integration surface for Products, Product models, Categories, Families, Attributes, Channels, locales, and related catalog resources. It supports collection queries, filtering, pagination, retrieval, creation, updates, and PATCH-style operations. | Martini can consume Akeneo REST endpoints, follow pagination, map responses, apply business rules, and call create or update operations in downstream systems or Akeneo. |
| Authentication | Yes | Akeneo REST API access uses OAuth 2.0 bearer tokens obtained through an API client and the associated user or connection permissions. | Martini can store client credentials and other secrets securely, obtain or refresh tokens through the configured authentication flow, and attach bearer tokens to API requests. |
| Webhooks / outbound callbacks | Limited | Akeneo provides webhook-style notifications for selected supported events and editions. They are not a universal event stream for every object or field change. | Martini can expose a secured REST API endpoint, receive the notification, validate it, retrieve the current Akeneo resource, and route the resulting workflow. |
| Bulk / async / batch APIs | Limited | Akeneo supports job-oriented import and export processing and collection or bulk-style operations for applicable resources. Exact behavior varies by endpoint, version, and edition. | Martini can start and monitor job-oriented processing, divide catalog reads into bounded pages or batches, persist checkpoints, and handle failed jobs explicitly. |
| File / attachment APIs | Yes | Akeneo supports media-file operations associated with product data, with asset and upload behavior depending on the edition and implementation. | Martini can retrieve media metadata, download files, transform metadata, and route files to commerce, DAM, storage, or other downstream systems where the relevant API operation is available. |
| Scheduled synchronization | Yes | Scheduled REST retrieval is appropriate for initial loads, incremental synchronization, and reconciliation where webhook coverage is incomplete or unavailable. | Martini workflows can run on schedules, retrieve filtered and paginated resources, checkpoint progress, and combine scheduled reconciliation with event-driven processing. |
| GraphQL APIs | Not confirmed | No official public Akeneo GraphQL API was confirmed in the supplied vendor documentation. | Martini should use the confirmed Akeneo REST API rather than assume GraphQL endpoints are available. |
| SOAP APIs | No | No official Akeneo SOAP API was confirmed. REST is the documented integration approach. | Martini can consume the Akeneo REST API instead of relying on SOAP integration. |
How Akeneo exposes data and business events
Akeneo REST APIs
Akeneo’s REST API is the principal mechanism for reading and updating catalog resources. It supports collection queries, filtering, pagination, resource retrieval, partial updates, media operations, and job-related import and export processes.
Martini implementation pattern
Martini implementation pattern: a workflow authenticates with OAuth 2.0, requests bounded collections or individual resources, follows Akeneo pagination, maps the response into a canonical or target model, applies validation and ownership rules, and writes the result to downstream APIs or Akeneo.
Implementation sequence
Akeneo Webhooks
Akeneo provides webhook-style notifications for selected events and editions. Coverage depends on the event type, configuration, version, and product edition, so notifications should not be treated as a complete change stream.
Martini implementation pattern
Martini implementation pattern: expose a secured Martini REST API endpoint, receive and validate the notification, use its identifiers to retrieve the current Product, Product model, or other supported resource, then process the complete resource through a workflow. Scheduled reconciliation supplements unsupported or missed events.
Implementation sequence
Akeneo Import and Export Jobs
Akeneo supports job-oriented catalog import and export processing and collection or bulk-style operations for applicable resources. Payload formats, limits, and supported resources vary by version and edition.
Martini implementation pattern
Martini implementation pattern: start or invoke the appropriate Akeneo job, monitor its status, process resulting data in bounded batches, persist checkpoints, and isolate failed records or jobs for operational review.
Implementation sequence
Akeneo Media and Asset Files
Akeneo supports media-file operations associated with product data, while asset capabilities and upload behavior depend on the target edition and implementation.
Martini implementation pattern
Martini implementation pattern: retrieve media or asset metadata, download or upload files through the applicable API operation, validate content and identifiers, and route binaries separately from catalog metadata to commerce, storage, or digital experience systems.
Implementation sequence
Common Akeneo integration patterns
Pattern 1: Publish Akeneo products to commerce
When to use this pattern
Use this pattern when Akeneo is the governed source for product content and commerce platforms need current descriptions, variants, categories, localized values, and media. It supports initial loads, scheduled incremental updates, and event-driven updates where Akeneo webhook coverage applies.
Integration direction
Example Mapping
| Akeneo Field | Canonical Field | Target Field |
|---|---|---|
| identifier | productSku | variant.sku |
| values.name | localizedProductName | title |
| categories | catalogCategories | productType |
| values.image | productMedia | images |
Martini implementation pattern
Martini retrieves changed Products and Product models, resolves Family and Channel rules, transforms localized and attribute-specific values, and upserts the target product using a stable identifier. Validation failures are isolated, transient API failures are retried with backoff, and periodic reconciliation detects missed or duplicated notifications.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- error handling
Pattern 2: Synchronize Akeneo catalog structures with Adobe Commerce
When to use this pattern
Use this pattern when Adobe Commerce requires a catalog hierarchy and product model aligned with Akeneo’s Categories, Families, Attributes, Products, and media. It is suitable for controlled catalog publication and repeatable reconciliation.
Integration direction
Example Mapping
| Akeneo Field | Canonical Field | Target Field |
|---|---|---|
| categories.parent | categoryParentId | parent_id |
| family | productTemplate | attribute_set_id |
| values.price | productPrice | price |
| associations | relatedProducts | related_product_links |
Martini implementation pattern
A Martini workflow reads Akeneo resources in dependency order, builds lookup maps for categories and attribute sets, transforms product and association structures, and submits bounded updates to Adobe Commerce. Checkpoints prevent full reloads on every run, while rejected products are captured with source identifiers for correction and replay.
Martini capabilities used
- scheduled workflows
- pagination
- data mapping
- business rules
- error handling
Pattern 3: Process selected Akeneo catalog events
When to use this pattern
Use this pattern when supported Akeneo events should trigger low-latency propagation without polling for every catalog change. Because webhook coverage is selective, the workflow should retrieve the current resource and be paired with scheduled reconciliation.
Integration direction
Example Mapping
| Akeneo Field | Canonical Field | Target Field |
|---|---|---|
| event.resource.identifier | sourceResourceId | entry.externalId |
| values.description | localizedDescription | entry.description |
| values.image | mediaReference | entry.productMedia |
| updated | sourceUpdatedAt | entry.sourceUpdatedAt |
Martini implementation pattern
Martini exposes a secured REST API endpoint for the Akeneo notification, validates the event, retrieves the current Product or Product model, and maps the complete resource to the target application. Event identifiers and source timestamps support idempotency; duplicate notifications are safely ignored and missing events are covered by reconciliation.
Martini capabilities used
- API exposure
- webhook consumption
- workflows
- data mapping
- idempotency
- error handling
Pattern 4: Enrich Akeneo products from operational systems
When to use this pattern
Use this pattern when an ERP or commerce platform owns operational attributes such as identifiers, pricing, inventory-related values, or technical data that must be reflected in Akeneo Products or Product models. Ownership rules should be explicit before enabling updates.
Integration direction
Example Mapping
| Akeneo Field | Canonical Field | Target Field |
|---|---|---|
| MaterialNumber | productIdentifier | identifier |
| BaseUnit | measurementUnit | values.measurement |
| GrossWeight | productWeight | values.weight |
| ProductStatus | publicationStatus | enabled |
Martini implementation pattern
Martini schedules source reads, normalizes operational values, validates them against Akeneo Family requirements, and sends supported create or update requests. The workflow applies field ownership rules, avoids overwriting editorial content, retries transient failures, and records source-to-Akeneo correlation details for audit and replay.
Martini capabilities used
- scheduled workflows
- API consumption
- data mapping
- validation
- business rules
- secrets management
Applications commonly integrated with Akeneo
Akeneo is commonly positioned as a governed product information source for commerce, ERP, and composable digital experiences. These integrations should be designed around ownership of product, operational, media, and publication data; Martini can orchestrate the relevant APIs and transformations without requiring a dedicated Akeneo connector.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Shopify | Publish product descriptions, variants, categories, media, and localized catalog content to an online storefront. | Akeneo → Martini → Shopify | A scheduled or event-driven Martini workflow retrieves changed Products, Product models, Categories, and media from Akeneo, applies channel and locale rules, maps attributes to Shopify structures, and retries or isolates failed product updates. |
| Adobe Commerce | Keep governed Akeneo product content and catalog structures aligned with Adobe Commerce storefronts. | Akeneo → Martini → Adobe Commerce | Martini consumes paginated Akeneo resources, transforms Families, Attributes, Categories, prices, and media into Adobe Commerce payloads, then records source identifiers and downstream outcomes for reconciliation. |
| Salesforce Commerce Cloud | Distribute product content and merchandising data from the PIM to Salesforce Commerce Cloud catalogs. | Akeneo → Martini → Salesforce Commerce Cloud | A Martini workflow retrieves filtered Akeneo catalog data, resolves localized and channel-scoped values, maps product and variant structures, and submits controlled updates to Salesforce Commerce Cloud with retry and error handling. |
| SAP S/4HANA | Exchange material, product, classification, or operational data between ERP-managed processes and Akeneo catalog content. | SAP S/4HANA → Martini → Akeneo | Martini retrieves approved source data from SAP S/4HANA, applies ownership and validation rules, maps the result to Akeneo Products or Product models, and calls the applicable Akeneo REST operations. |
| NetSuite | Synchronize item and product information between ERP-managed records and Akeneo catalog data. | NetSuite → Martini → Akeneo | Martini schedules incremental reads from NetSuite, normalizes identifiers and operational attributes, validates Family-specific requirements, and creates or updates supported Akeneo resources while preserving idempotency. |
| Pimcore | Exchange catalog or master-data content when an organization operates multiple PIM, MDM, or content platforms. | Akeneo → Martini → Pimcore | Martini mediates the two APIs with a canonical product model, applies conflict and ownership rules, transforms localized attributes and associations, and routes rejected records to an operational error process. |
| Contentful | Deliver structured product content to digital experiences alongside product information maintained in Akeneo. | Akeneo → Martini → Contentful | Martini retrieves approved Akeneo content, maps product references and localized fields to Contentful models, handles media references separately, and uses event notifications plus periodic reconciliation where supported. |
How to build a Akeneo integration in Martini
Objective
Establish an authenticated connection to the target Akeneo tenant and confirm the API user or connection has the required permissions for the selected resources.
Instructions in Martini
- Configure the Akeneo base URL and REST API settings
- Store OAuth client credentials and related secrets in Martini secrets management
- Implement bearer-token acquisition and renewal
- Verify access with a least-privilege API user
Objective
Select an execution model that matches the synchronization requirement and the coverage available in the Akeneo edition.
Instructions in Martini
- Use a Martini REST API endpoint for supported Akeneo webhook notifications
- Use a scheduler for initial loads, incremental reads, and reconciliation
- Combine event-driven processing with scheduled completeness checks
- Define the source resources and event types in scope
Objective
Read Products, Product models, Categories, Families, Attributes, Channels, media, or job results without assuming a single response contains the complete catalog.
Instructions in Martini
- Request filtered or bounded collections
- Follow Akeneo pagination information
- Retrieve the current resource after a webhook notification
- Persist a cursor, timestamp, page position, or job reference
Objective
Coordinate API calls, dependencies, batching, file processing, downstream writes, and recovery behavior in a maintainable Martini workflow.
Instructions in Martini
- Separate catalog metadata processing from binary media transfer
- Process pages or batches with controlled concurrency
- Use reusable workflow logic for authentication and resource retrieval
- Route invalid or failed items to an operational error path
Objective
Translate Akeneo’s configurable, localized, channel-specific catalog model into the target application’s structure.
Instructions in Martini
- Use Family and Attribute information to drive mappings
- Resolve locale and Channel context explicitly
- Transform Product models, variants, associations, and media references
- Normalize identifiers, prices, measurements, dates, and select values
Objective
Enforce ownership, publication, validation, and idempotency rules before writing data to Akeneo or downstream systems.
Instructions in Martini
- Validate required Family-specific attributes
- Apply channel and locale publication rules
- Use stable Akeneo identifiers for upserts
- Prevent editorial fields from being overwritten by operational sources
Common Akeneo data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Products | Sellable catalog items containing identifiers, attribute values, associations, quantities, and channel- or locale-specific data. | Shopify, Adobe Commerce, Salesforce Commerce Cloud, Contentful, SAP S/4HANA | Martini retrieves, validates, maps, and upserts Products using stable identifiers; it can also process associated media and preserve locale and channel context. |
| Product models | Reusable structures for variant products and shared product information. | Shopify, Adobe Commerce, Salesforce Commerce Cloud, NetSuite | Martini distinguishes Product models from variant Products, maps family- and variant-specific attributes, and applies idempotent create or update rules. |
| Categories | Hierarchical catalog classifications assigned to Products or Product models. | Shopify, Adobe Commerce, Salesforce Commerce Cloud, Contentful | Martini traverses or retrieves category data, resolves parent-child relationships, and maps the hierarchy to the target catalog model. |
| Families | Product templates defining the attributes applicable to a product type. | Adobe Commerce, Salesforce Commerce Cloud, SAP S/4HANA, NetSuite | Martini uses Family information to drive validation and dynamic mapping, accounting for different required and optional attribute sets. |
| Attributes | Product data fields such as descriptions, dimensions, prices, images, and technical specifications. | Shopify, Adobe Commerce, Salesforce Commerce Cloud, Contentful | Martini transforms select, metric, price, date, reference-data, localized, and channel-scoped values according to target-system rules. |
| Channels | Catalog contexts or destinations that determine how product data is organized and localized for publication. | Shopify, Adobe Commerce, Salesforce Commerce Cloud, Contentful | Martini uses Channel context to select publishable data, route records to the correct target, and prevent unintended cross-channel updates. |
Authentication and security considerations
OAuth 2.0 access
Akeneo REST API access uses OAuth 2.0 bearer tokens. API clients are associated with users or connections whose permissions determine the resources available to the integration.
Credential protection
Store Akeneo client credentials, user credentials where required, access tokens, and webhook secrets in Martini secrets management rather than embedding them in workflows.
Least privilege
- Use an Akeneo API user or connection with only the permissions required by the integration.
- Separate credentials for development, testing, and production tenants where appropriate.
- Protect Martini webhook endpoints with authentication and validation controls.
Operational considerations for Akeneo integrations
Pagination and scale
Akeneo collection responses are paginated. Use bounded pages, filtered reads, controlled concurrency, and persisted checkpoints instead of loading an entire catalog into memory.
Events and reconciliation
Webhook coverage is selective and notifications may be duplicated or delayed. Retrieve the current resource after a notification and run scheduled reconciliation for completeness.
Catalog variability
Families, Attributes, Channels, locales, variants, associations, and enabled modules can differ between tenants. Treat the target edition and version as authoritative and test mappings against representative catalog data.
Retries and idempotency
- Use stable Akeneo identifiers for safe retries and upserts.
- Apply backoff for transient failures and throttling responses.
- Capture the resource identifier, endpoint, HTTP status, correlation information, and retry count.
- Separate failed records from successful batches where possible.
Files and jobs
Process media binaries separately from catalog metadata, validate content types and sizes, and monitor import or export job status explicitly.
Why use Martini instead of scripts or point-to-point integrations?
Orchestrate more than API calls
Martini coordinates authentication, pagination, webhooks, scheduled reconciliation, catalog jobs, media handling, downstream writes, and recovery behavior in maintainable workflows.
Adapt to Akeneo’s catalog model
Mappings and business rules can account for Family-specific attributes, localized and channel-scoped values, Product models, associations, and configurable tenant schemas.
Reduce point-to-point duplication
Reusable workflows and APIs allow common authentication, validation, transformation, checkpointing, and error-handling logic to be shared across commerce, ERP, and digital experience integrations.
Improve operational control
- Combine low-latency event processing with scheduled reconciliation.
- Apply consistent retries, idempotency, and failure isolation.
- Expose normalized APIs to downstream applications when a controlled façade is useful.
- Use workflow logs and monitoring to troubleshoot catalog synchronization.
Frequently asked questions
Akeneo is primarily integrated through its REST API, which exposes catalog resources such as Products, Product models, Categories, Families, Attributes, and Channels. Selected Akeneo editions and configurations also support webhook-style notifications, while import and export jobs support larger catalog processes. OAuth 2.0 secures API access, and integrations commonly combine event-driven processing with scheduled pagination and reconciliation.
Yes. Martini can consume Akeneo’s REST API, authenticate with OAuth 2.0, receive supported Akeneo webhook notifications through a Martini REST API, process media and catalog jobs, and orchestrate mappings and downstream updates. No native Martini Akeneo connector is documented in the supplied sources.
No. A dedicated Akeneo connector is not required. Martini can use Akeneo’s confirmed native integration mechanisms, including REST APIs, OAuth 2.0 authentication, selected webhook notifications, job-oriented processing, and media-file operations.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Akeneo. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Akeneo, cloud infrastructure, or other third-party systems depending on subscription, usage, and deployment model.
Use Akeneo’s REST API as the primary method for catalog reads and writes. Use webhook-style notifications for selected supported events, job-oriented import or export processing for appropriate bulk workloads, and media operations for files. GraphQL and SOAP should not be assumed because they were not confirmed in the supplied Akeneo documentation.
Akeneo provides webhook-style notifications for selected events, editions, versions, and configurations, but not a universal event stream for every object or field change. Martini can receive a notification, validate it, retrieve the current resource, and process it; scheduled reconciliation remains important for unsupported or missed changes.
Mappings should account for Family-specific attributes, Product models and variants, localized and channel-scoped values, select and metric types, prices, dates, reference data, associations, and optional fields. Martini can transform these structures into a canonical or target model and apply validation and ownership rules before writing updates.
Martini workflows can process bounded pages, follow Akeneo pagination information, persist checkpoints, retry transient failures with backoff, and isolate invalid records. Stable Product and Product model identifiers support idempotent upserts, while event identifiers or source references can help suppress duplicate notifications. Workflow logs and error paths provide operational visibility.
Related Martini documentation
API Integration
Workflows
Connect Akeneo with your enterprise systems
Use Martini to build secure, maintainable Akeneo integrations that synchronize catalog data, process selected events, transfer media, and coordinate commerce, ERP, and digital experience workflows.