.png)
Adobe Commerce Integration Guide
Integrate Adobe Commerce with enterprise systems through REST and GraphQL APIs, selected webhooks and events, asynchronous operations, and secure workflow orchestration.
Adobe Commerce integration options at a glance
Adobe Commerce provides REST APIs for administrative, customer, guest, catalog, order, inventory, pricing, and cart operations, while GraphQL is suited to storefront and headless use cases. SOAP remains available for existing WSDL-based integrations. Selected webhook-style notifications and Adobe Commerce event mechanisms can support event-driven workflows, although coverage depends on the deployment and enabled services. Bulk and asynchronous APIs support larger exchanges, and media APIs handle catalog assets. Authentication includes integration tokens, admin and customer tokens, OAuth-based credentials, and ACL permissions. Martini can consume these interfaces, transform payloads, orchestrate workflows, and expose APIs for downstream systems.
| Integration point | Supported by Adobe Commerce? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs | Yes | Administrative, catalog, customer, guest, cart, order, inventory, pricing, and other Commerce operations use REST resources. | Martini can consume Adobe Commerce REST endpoints from workflows, map responses and requests, apply validation, and expose APIs for downstream consumers. |
| GraphQL APIs | Yes | GraphQL supports storefront and headless queries and mutations for products, categories, carts, customers, orders, and related operations. | Martini can consume GraphQL operations when selective fields, storefront-oriented reads, or GraphQL-specific mutations are appropriate. |
| SOAP APIs | Yes | SOAP is available through the Web API framework and is primarily relevant to existing WSDL-based enterprise integrations. | Martini can consume SOAP services and process XML responses where a legacy or contract-specific integration requires them. |
| Webhooks and outbound callbacks | Limited | Adobe Commerce supports webhook-style outbound calls for selected events and use cases; coverage is not universal across Commerce objects or transitions. | Martini can receive supported notifications through an API or webhook-triggered workflow, validate them, apply idempotency, and retrieve the current resource. |
| Adobe Commerce events | Limited | Adobe Commerce event mechanisms and Adobe I/O Events can provide event-driven capabilities, subject to edition, deployment, enabled services, and event coverage. | Martini can receive or consume confirmed event notifications and combine them with REST or GraphQL reads for complete resource state. |
| Bulk and asynchronous APIs | Yes | Asynchronous and bulk Web API operations support larger catalog, customer, inventory, and order-related exchanges. | Martini can submit operations, persist operation identifiers, poll or retrieve results, and route partial failures for retry or review. |
| File and media APIs | Limited | Media APIs support catalog images and related product media; Adobe Commerce is not a universal document or attachment repository. | Martini can transfer confirmed media metadata or files and map them to target systems, while requiring verification for invoices, shipment documents, or customer files. |
| Authentication | Yes | Integration tokens, admin and customer tokens, OAuth-based credentials, HTTPS, and ACL-controlled permissions support different integration contexts. | Martini can store credentials in secure configuration, call authenticated endpoints, and separate authorization failures from retryable transport errors. |
| Database access | Limited | Adobe Commerce uses a relational database, but direct SQL access is deployment-dependent and is not the preferred business integration contract. | Martini can use SQL for organization-controlled staging, audit, reconciliation, or state stores without bypassing Commerce APIs for operational writes. |
How Adobe Commerce exposes data and business events
Adobe Commerce REST APIs
Adobe Commerce REST APIs provide the broadest operational interface for administrative, catalog, customer, cart, order, inventory, pricing, and other Commerce resources. They are the primary choice for many enterprise synchronization and write-back processes.
Martini implementation pattern
Martini implementation pattern: a workflow calls the required REST resources, handles pagination and authentication, normalizes the response, applies business rules, and writes the mapped result to another system or back to Adobe Commerce. Martini can also expose an API façade that hides provider-specific details from consuming applications.
Implementation sequence
Adobe Commerce GraphQL APIs
Adobe Commerce GraphQL supports storefront and headless queries and mutations for products, categories, carts, customers, orders, and other operations. The available schema and authorization context vary by operation and deployment.
Martini implementation pattern
Martini implementation pattern: a workflow sends a defined GraphQL query or mutation when selective fields, storefront-oriented reads, or GraphQL-specific operations are more suitable than REST. The workflow validates the response, handles GraphQL errors separately from transport errors, and maps the selected fields into a canonical or target model.
Implementation sequence
Adobe Commerce webhooks and events
Adobe Commerce supports webhook-style outbound calls for selected events, and event mechanisms associated with Adobe Commerce services and Adobe I/O Events may be available depending on the edition, deployment, and enabled services. Event coverage must be confirmed for the target environment.
Martini implementation pattern
Martini implementation pattern: Martini exposes an API or webhook-triggered workflow to receive the notification, validates its authenticity and shape, uses a durable idempotency key, and retrieves the current Commerce resource through REST or GraphQL. Where no suitable event exists, a scheduled incremental read can provide a controlled fallback.
Implementation sequence
Adobe Commerce bulk and asynchronous APIs
Adobe Commerce provides asynchronous and bulk Web API operations for larger workloads, including catalog, customer, inventory, and order-related processing. These operations help reduce synchronous request timeouts but require operation tracking.
Martini implementation pattern
Martini implementation pattern: a workflow submits a bulk or asynchronous request, stores the returned operation identifier, polls or retrieves the result, and separates submitted, completed, and partially failed items. Martini can retry transient failures while routing invalid individual items to reconciliation or operational review.
Implementation sequence
Common Adobe Commerce integration patterns
Pattern 1: Synchronize orders to an ERP
When to use this pattern
Use this pattern when Adobe Commerce orders must be posted to an ERP or fulfillment platform and shipment, invoice, cancellation, or credit-memo status must return to Commerce. It is suitable for event-assisted processing with scheduled reconciliation.
Integration direction
Example Mapping
| Adobe Commerce Field | Canonical Field | Target Field |
|---|---|---|
| entity_id | commerceOrderId | ExternalOrderReference |
| increment_id | orderNumber | SalesOrderNumber |
| items[].sku | lineItemSku | MaterialNumber |
| grand_total | orderTotal | DocumentAmount |
Martini implementation pattern
A Martini workflow receives a confirmed notification or retrieves newly placed Orders, then fetches complete order context including Customers, addresses, payment state, and items. It validates required fields, prevents duplicate posting using entity or increment identifiers, transforms the order into the ERP model, and retries transient failures while routing validation or posting errors for review. A separate flow maps fulfillment and financial status back to Adobe Commerce.
Martini capabilities used
- workflows
- API consumption
- data mapping
- business rules
- idempotency
- error handling
- scheduled synchronization
Pattern 2: Synchronize products and inventory
When to use this pattern
Use this pattern when Adobe Commerce is the catalog or commerce channel and product, category, price, or inventory data must be published to another platform or updated from an ERP or warehouse system. Product types, store scope, sources, stocks, and reservations should be modeled explicitly.
Integration direction
Example Mapping
| Adobe Commerce Field | Canonical Field | Target Field |
|---|---|---|
| sku | productSku | objectID |
| name | productName | name |
| price | sellingPrice | price |
| extension_attributes.stock_item.qty | availableQuantity | inventoryQuantity |
Martini implementation pattern
Martini can run a scheduled or event-assisted workflow that pages through Products and Categories, expands the required attributes, and maps them to the search or channel model. Inventory updates can be sent in the opposite direction after applying ownership, reservation, and salable-quantity rules. Bulk or asynchronous APIs support larger loads, while checkpointing and retries prevent missed or repeated updates.
Martini capabilities used
- scheduled workflows
- API consumption
- pagination
- data transformation
- bulk orchestration
- business rules
- retry handling
Pattern 3: Synchronize customers and marketing events
When to use this pattern
Use this pattern when Adobe Commerce customer profiles, Customer Groups, catalog context, or order activity must be made available to a customer or marketing platform. The implementation should define identity ownership, consent handling, and the permitted customer scope.
Integration direction
Example Mapping
| Adobe Commerce Field | Canonical Field | Target Field |
|---|---|---|
| id | customerId | externalProfileId |
| emailAddress | ||
| group_id | customerSegmentId | segmentReference |
| orders[].increment_id | orderNumber | commerceEventOrder |
Martini implementation pattern
A Martini workflow retrieves changed Customers and related commerce activity through appropriately authorized APIs, filters consent-sensitive fields, maps Adobe Commerce identifiers and groups to the marketing model, and submits controlled batches. Duplicate profile and event keys are checked before writes, and invalid consent or schema data is routed to an exception path rather than retried indefinitely.
Martini capabilities used
- workflows
- API consumption
- data mapping
- validation
- privacy and consent rules
- batch processing
- error handling
Pattern 4: Reconcile orders, invoices, and inventory
When to use this pattern
Use this pattern when operational teams need to detect missing, duplicated, or inconsistent data between Adobe Commerce and downstream systems. It is especially useful after high-volume asynchronous processing, delayed events, or multi-system fulfillment activity.
Integration direction
Example Mapping
| Adobe Commerce Field | Canonical Field | Target Field |
|---|---|---|
| increment_id | orderNumber | SalesOrderNumber |
| invoice.entity_id | invoiceId | ExternalInvoiceId |
| shipment.entity_id | shipmentId | ExternalFulfillmentId |
| credit_memo.entity_id | creditMemoId | ExternalCreditMemoId |
Martini implementation pattern
A scheduled Martini workflow retrieves scoped Orders and related Invoices, Shipments, and Credit Memos, compares them with downstream references, and stores reconciliation state in an organization-controlled data store. It identifies missing or conflicting objects, applies an overlap window for delayed updates, reprocesses eligible discrepancies, and produces an operational exception result for unresolved cases.
Martini capabilities used
- scheduler triggers
- workflow orchestration
- API consumption
- SQL state management
- comparison rules
- idempotency
- monitoring
Applications commonly integrated with Adobe Commerce
Adobe Commerce commonly participates in broader commerce, ERP, customer, payment, tax, marketing, and search architectures. The specific objects and direction of exchange should be defined for each implementation, with clear ownership for products, inventory, customers, orders, and financial status.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize Adobe Commerce customers, customer groups, order context, and commerce activity with customer and service processes in Salesforce. | Adobe Commerce → Martini → Salesforce | Martini can retrieve Customers, Customer Groups, and Orders through REST or selected GraphQL operations, map them to Salesforce objects, apply identity and consent rules, and record external identifiers for idempotent updates. |
| SAP S/4HANA | Exchange products, pricing, inventory, customers, orders, invoices, and fulfillment information between commerce operations and ERP processes. | Adobe Commerce → Martini → SAP S/4HANA | A scheduled or event-assisted Martini workflow can page through Adobe Commerce resources, transform product and order structures into SAP business messages, control concurrency, and route validation or posting failures for reconciliation. |
| NetSuite | Synchronize catalog, customers, sales orders, inventory, invoices, and fulfillment status between Adobe Commerce and financial or operational processes. | Adobe Commerce → Martini → NetSuite | Martini can use Adobe Commerce REST or asynchronous APIs for high-volume reads, map Orders and related objects to NetSuite records, send inventory and financial updates in the opposite direction, and maintain a durable cross-reference ledger. |
| Shopify | Coordinate product, inventory, and order information across multiple commerce channels when Adobe Commerce and Shopify operate in the same enterprise landscape. | Adobe Commerce → Martini → Shopify | Martini can designate ownership by object, normalize Products, Categories, inventory, and Orders into a canonical model, apply duplicate-order controls, and route channel-specific transformations to each platform. |
| Avalara | Support tax calculation and tax transaction reconciliation for Adobe Commerce orders, invoices, refunds, and cancellations. | Adobe Commerce → Martini → Avalara | A Martini workflow can send normalized cart or order tax inputs to Avalara, validate the response before updating the Commerce process, and reconcile tax results against invoices, refunds, or credit memos. |
| Stripe | Coordinate payment status, refunds, disputes, and payment-related information with Adobe Commerce order and financial processes. | Adobe Commerce → Martini → Stripe | Martini can orchestrate payment-related API calls and status events, correlate them to Adobe Commerce Orders, apply non-duplication rules for payment actions, and separate transient provider errors from authorization or business failures. |
| Klaviyo | Transfer customer, catalog, order, and behavioral data from Adobe Commerce to support segmentation and marketing automation. | Adobe Commerce → Martini → Klaviyo | Martini can retrieve changed Customers, Products, and Orders, map attributes and event payloads to Klaviyo’s model, filter consent-sensitive data, and process records in controlled batches. |
How to build a Adobe Commerce integration in Martini
Objective
Establish Adobe Commerce access using an integration with narrowly scoped ACL resources and the authentication method appropriate to the workflow.
Instructions in Martini
- Configure the Adobe Commerce base URL and API credentials in secure Martini environment configuration.
- Prefer integration tokens for server-to-server access and use customer-scoped authorization where required.
- Separate credential failures from transient transport errors.
Objective
Select an event, webhook, API-led, or scheduled trigger based on the confirmed coverage for the Adobe Commerce environment.
Instructions in Martini
- Use a webhook or event-triggered workflow only for confirmed event coverage.
- Use a scheduler for incremental reads, reconciliation, or unsupported event cases.
- Define the scope, overlap window, and checkpoint strategy.
Objective
Retrieve the current Adobe Commerce resource rather than relying solely on a notification payload, especially when the event contains limited state.
Instructions in Martini
- Call REST or GraphQL resources according to the use case.
- Page through collections and persist progress.
- Use asynchronous or bulk APIs for larger workloads and track operation identifiers.
Objective
Coordinate calls, enrichment, validation, routing, and downstream writes in a maintainable Martini workflow.
Instructions in Martini
- Separate acquisition, transformation, business rules, and delivery stages.
- Use reusable services or workflow components for repeated provider logic.
- Control concurrency when Adobe Commerce or its hosting layer has limited capacity.
Objective
Convert Adobe Commerce Products, Customers, Orders, inventory, or other objects into the canonical and target models.
Instructions in Martini
- Model store, website, and store-view scope explicitly.
- Handle product types, order lifecycle states, inventory reservations, and custom attributes.
- Validate required fields before making non-idempotent writes.
Objective
Enforce ownership, duplicate prevention, consent, status, pricing, inventory, and exception rules before delivery.
Instructions in Martini
- Use stable identifiers such as entity IDs, increment IDs, SKUs, or external references.
- Define which system owns each object and status field.
- Route unsupported transitions and validation failures for review.
Common Adobe Commerce data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Products | Synchronize catalog items, product types, attributes, prices, and availability across commerce, PIM, search, or marketplace systems. | SAP S/4HANA, NetSuite, Shopify, Algolia, Klaviyo | Martini retrieves and pages product data, distinguishes simple, configurable, grouped, bundle, virtual, and downloadable structures, then maps parent-child and attribute relationships. |
| Categories | Share catalog hierarchy, category assignments, and navigation structure with external commerce, search, or marketing platforms. | Shopify, Algolia, Klaviyo, external storefronts | Martini maps category identifiers, parent relationships, store scope, and localized values while applying target-specific hierarchy rules. |
| Customers | Synchronize registered customer profiles, addresses, identity attributes, and commerce activity with customer platforms. | Salesforce, NetSuite, Klaviyo, loyalty platforms | Martini uses appropriately scoped authorization, maps customer identifiers and consent-related fields, and applies duplicate and ownership rules before writes. |
| Customer Groups | Exchange customer segmentation and pricing-group information with CRM, loyalty, or downstream pricing processes. | Salesforce, NetSuite, Klaviyo | Martini translates group identifiers and business meaning into target segmentation models and preserves the Adobe Commerce group reference. |
| Carts / Quotes | Support storefront, guest, customer, pricing, shipping, payment, and totals workflows before an order is placed. | Headless storefronts, payment services, Avalara, Salesforce | Martini can consume REST or GraphQL cart operations, validate totals and context, and orchestrate external tax or payment calls without assuming every cart operation is interchangeable. |
| Orders | Coordinate placed orders, order items, customer and address data, payment state, invoices, shipments, cancellations, and credit memos. | SAP S/4HANA, NetSuite, Salesforce, warehouse systems, Stripe | Martini retrieves complete order context, maps lifecycle states, enforces idempotency using stable identifiers, and sends status updates back through confirmed Adobe Commerce APIs. |
Authentication and security considerations
Use scoped Adobe Commerce integrations
Adobe Commerce supports integration access tokens, admin and customer tokens, OAuth-based authentication, HTTPS, and ACL-controlled permissions. Create separate integrations for environments or business domains where practical, and grant only the resources required by each Martini workflow.
Protect credentials and customer data
Store tokens and credentials in secure Martini configuration rather than workflow definitions. Use customer-scoped authorization for customer-facing operations when appropriate, and treat customer, payment, address, and consent data according to organizational security requirements.
- Transmit API credentials only over HTTPS.
- Rotate integration credentials and distinguish expired credentials from retryable failures.
- Do not use broad administrator access when a restricted integration can perform the operation.
Operational considerations for Adobe Commerce integrations
Plan for platform behavior
Adobe Commerce collections and GraphQL connections can paginate, and effective request limits may be imposed by Commerce, hosting, a web application firewall, an API gateway, or infrastructure capacity. Use controlled concurrency, backoff, batching, and asynchronous or bulk APIs for larger workloads.
Design for reliable synchronization
- Use stable identifiers and durable idempotency records for webhook deliveries, retries, and scheduled overlap windows.
- Track asynchronous operation identifiers and process partial failures separately from completed items.
- Confirm event coverage for the specific edition, version, extensions, and deployment.
- Model website, store, store-view, product-type, inventory-source, reservation, and order-lifecycle scope explicitly.
- Version mappings and validate custom attributes or schema changes introduced by extensions.
- Capture response status, error messages, object identifiers, correlation information, and Martini workflow execution details.
Why use Martini instead of scripts or point-to-point integrations?
Coordinate complete integration behavior
Point-to-point scripts often combine authentication, pagination, mapping, retries, and business rules in code that is difficult to govern. Martini provides workflows and APIs for coordinating Adobe Commerce calls with ERP, customer, fulfillment, payment, tax, search, and marketing systems.
Make integrations reusable and maintainable
Martini can consume REST, GraphQL, and SOAP APIs, receive confirmed webhook notifications, orchestrate asynchronous operations, expose controlled APIs, and apply reusable mapping and validation logic. This supports real-time, scheduled, batch, and reconciliation patterns without treating Adobe Commerce as an unrestricted database.
- Centralize secure environment configuration and credentials.
- Reuse canonical mappings, validation, and error-handling patterns.
- Monitor workflows and preserve processing state for recovery and audit.
- Extend implementation logic when provider-specific transformation or reconciliation rules require custom code.
Frequently asked questions
Adobe Commerce can be integrated through REST APIs, GraphQL APIs, SOAP services, selected webhook-style notifications and event mechanisms, and bulk or asynchronous Web API operations. REST is generally suited to broad operational resources, GraphQL to storefront and headless use cases, and scheduled workflows to changes that are not covered by events.
Yes. Martini can integrate with Adobe Commerce by consuming its REST, GraphQL, or SOAP APIs, receiving supported webhook or event notifications, and orchestrating asynchronous or bulk operations. Martini can transform Commerce data, apply business rules, synchronize target systems, and expose APIs for downstream applications.
No. A dedicated Adobe Commerce connector is not required. Martini can use Adobe Commerce’s native REST, GraphQL, SOAP, webhook, event, asynchronous, bulk, and authentication mechanisms through workflows and APIs.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Adobe Commerce. The integration is subject to the provisioned capacity of the Martini environment. Separate costs may apply from Adobe, hosting providers, payment or tax services, infrastructure, or other third-party systems based on their subscriptions, usage, and deployment models.
REST is usually the broadest choice for administrative and operational resources such as Products, Customers, Orders, inventory, and asynchronous operations. GraphQL is useful for storefront and headless scenarios requiring selected fields or GraphQL-specific mutations. SOAP remains relevant to existing WSDL-based integrations or systems with a contract-specific requirement.
Adobe Commerce supports webhook-style notifications for selected events and has event mechanisms whose availability depends on the edition, deployment, enabled services, and event coverage. They should not be assumed to cover every object or state transition. Martini can receive confirmed notifications and use scheduled incremental reads where event coverage is insufficient.
Martini workflows can retrieve or receive Products, Categories, Customers, Customer Groups, Carts, Orders, inventory, and related objects, then map them to canonical and target models. Workflows can page through collections, use bulk APIs, apply store and website scope, enforce ownership and validation rules, and write updates to downstream systems or back to Adobe Commerce.
Martini can distinguish transient transport or infrastructure failures from authorization, validation, and duplicate-object errors. Workflows can use controlled retries and backoff, durable checkpoints, operation tracking for asynchronous requests, and idempotency keys based on event identifiers or stable Commerce identifiers. Unresolved failures can be routed to reconciliation and operational review.
Related Martini documentation
Workflows
Operations
Integrate Adobe Commerce with Martini
Connect Adobe Commerce APIs, events, and asynchronous operations to enterprise workflows with secure authentication, reliable data synchronization, and maintainable transformation logic.