Adobe Commerce Cloud Service: de oktoberrelease opent de backoffice voor integraties

Op Adobe Commerce as a Cloud Service zijn de spelregels veranderd: geen eigen PHP-modules, geen directe databasetoegang. Wat de API niet kan, kan uw integratie ook niet. Daarom verdient de release van 7 oktober 2026 een aandachtige lezing: van een dozijn nieuwigheden vergroten bijna alle de integratieoppervlakte — winkelwagens, prijzen, B2B, e-mail. Dit is wat er opengaat, en de beperking die erbij hoort.

De winkelwagen opent zich voor externe systemen

Drie nieuwigheden mikken op hetzelfde scenario: een extern systeem — een OMS, een callcenter, een tool voor begeleide verkoop — dat winkelwagens moet aanmaken of wijzigen zonder de klant te storen.

• De maatwerkprijs. Het extensieattribuut custom_price maakt het mogelijk een willekeurige prijs op een winkelwagenregel te zetten via de standaard REST-endpoints, voorbehouden aan admin- en integratietokens. Onderhandelde offertes, callcentertarieven, commerciële gebaren: tot nu toe moest u winkelwagenregels misbruiken om dit alles na te bootsen.
• De geïsoleerde winkelwagens. Een optie, standaard uitgeschakeld, scheidt de door admins of integraties aangemaakte winkelwagens van de actieve storefront-winkelwagen van de klant. Gedaan met de offertewagen die de wagen overschrijft die de klant op datzelfde moment aan het vullen was.
• De vrije verzendkorting. Een admin-endpoint past een willekeurige verzendkorting toe op een winkelwagen, voor gevallen die de standaardregels niet dekken — gratis verzending na een incident, een contractueel onderhandelde voorwaarde.

De catalogusprijzen verlaten het adminscherm

Catalogusprijsregels worden nu via REST beheerd: aanmaken, wijzigen, verwijderen, zoeken en metadata ontdekken. Een pricing-engine of een PIM kan de regels eindelijk synchroniseren in plaats van handmatige invoer te eisen. En die regels zijn nu op het uur te plannen, niet alleen op de dag: een flash sale van 9 tot 13 uur vraagt geen zelfgebouwd script meer.

In B2B weet de webhook met wie hij praat

De webhook voor verzendtarieven ontvangt nu de company_id van de winkelwagen en de aangepaste attributen van het bedrijf: een App Builder-integratie kan beslissen of een onderhandeld tarief van toepassing is zonder Commerce opnieuw aan te roepen. Twee sloten komen tegelijk aan: een optie blokkeert bedrijfsregistratie door niet-geauthenticeerde gasten (mutation createCompany), en reCAPTCHA kan presigned bestandsuploads beschermen. Aan de retourkant accepteert de REST-API aangepaste attributen op retourregels — het synchroniseren van RMA’s met een ERP hoeft niet langer via de storefront-GraphQL.

De transactionele e-mails verlaten de monoliet

Nieuwe events maken het mogelijk transactionele e-mails te versturen vanaf een extern platform — Salesforce Marketing Cloud bijvoorbeeld — via App Builder. Voor merchants die hun marketingcampagnes al in een ESP beheren, is dit de kans om te consolideren: dezelfde sjablonen, dezelfde deliverability, dezelfde rapportage voor de orderbevestiging en de nieuwsbrief.

De beperking die bij de opening hoort

Eén regel van de release voegt niets toe en kan bestaande code breken: de Bulk API dwingt nu een maximum aantal entiteiten per verzoek af, niet configureerbaar, met een fout daarboven. Als uw imports massale batches versturen, controleer ze dan vóór de volgende volledige synchronisatie — opdelen in blokken wordt de norm, geen optimalisatie.

Waar te beginnen

• Haal de integratiebacklog boven die « in afwachting van de API » bevroren was en leg hem naast deze release: catalogusprijsregels, maatwerkprijzen en verzendkortingen staan er misschien al op.
• Controleer uw gebruik van de Bulk API: batchgroottes, foutafhandeling bij de nieuwe limiet.
• Activeer in B2B de registratiebeperking en bestudeer de verrijkte webhook als uw verzendtarieven afhangen van het klantcontract.
• Als een e-mailvernieuwing wacht, wordt de eventroute naar een externe ESP de standaardoptie op de cloudservice.

Op een SaaS-platform is de roadmap van de leverancier ook de uwe: wat de API vandaag niet biedt, is niet « te ontwikkelen », maar « af te wachten ». De oktoberrelease toont dat het wachten kort kan zijn — en dat een ongedateerde gatenlijst, ook hier, een foute lijst is.