Adobe Commerce Cloud Service: the October release opens the back office to integrations

On Adobe Commerce as a Cloud Service, the rules of the game have changed: no custom PHP modules, no direct database access. If the API cannot do it, your integration will not do it either. That is why the 7 October 2026 release deserves a close read: of a dozen new capabilities, nearly all widen the integration surface — carts, pricing, B2B, email. Here is what opens up, and the constraint that comes with it.

The cart opens up to third-party systems

Three additions target the same scenario: an external system — an OMS, a call centre, an assisted-selling tool — that needs to create or edit carts without disturbing the shopper.

• Custom prices. The custom_price extension attribute lets you set an arbitrary price on a cart line through the standard REST endpoints, restricted to admin and integration tokens. Negotiated quotes, call-centre pricing, goodwill gestures: until now, you had to bend cart price rules to fake all of this.
• Isolated carts. An option, disabled by default, separates carts created by admins or integrations from the customer’s active storefront cart. No more quote cart overwriting the basket the customer was filling at the same moment.
• Free-form shipping discounts. An admin endpoint applies an arbitrary shipping discount to a cart, for cases standard rules do not cover — free shipping after an incident, a condition negotiated in the contract.

Catalog pricing leaves the admin screen

Catalog price rules can now be managed over REST: create, update, delete, search and metadata discovery. A pricing engine or a PIM can finally synchronise rules instead of demanding manual entry. And those rules can now be scheduled to the hour, not just the day: a flash sale from 9 am to 1 pm no longer needs a homemade script.

In B2B, the webhook knows who it is talking to

The shipping-rates webhook now receives the cart’s company_id and the company’s custom attributes: an App Builder integration can decide whether a negotiated rate applies without calling Commerce back. Two locks arrive at the same time: a configuration option blocks company registration by unauthenticated guests (the createCompany mutation), and reCAPTCHA can protect presigned file uploads. On returns, the REST API accepts custom attributes on return items — synchronising RMAs with an ERP no longer detours through the storefront GraphQL.

Transactional email leaves the monolith

New events let you send transactional emails from a third-party platform — Salesforce Marketing Cloud, for instance — through App Builder. For merchants already running marketing campaigns in an ESP, this is the chance to consolidate: same templates, same deliverability, same reporting for the order confirmation and the newsletter.

The constraint that comes with the opening

One line in the release adds nothing and can break existing code: the Bulk API now enforces a maximum number of entities per request, non-configurable, returning an error beyond it. If your imports push massive batches, check them before the next full synchronisation — chunking becomes the norm, not an optimisation.

Where to start

• Dust off the integration backlog frozen “until the API exists” and cross it against this release: catalog price rules, custom prices and shipping discounts may already be on it.
• Review your Bulk API usage: batch sizes, error handling on the new limit.
• In B2B, enable the company-registration restriction and look at the enriched webhook if your shipping rates depend on the customer contract.
• If an email revamp is waiting, the events route to a third-party ESP becomes the default option on the cloud service.

On a SaaS platform, the vendor’s roadmap is also yours: what the API does not offer today is not “to be built”, it is “to be waited for”. The October release shows the wait can be short — and that an undated gap list, here too, is a wrong list.