Op deze pagina
Deze deadline is belangrijk omdat authenticatie de toegang vormt tot elke retour of ruiling die klanten zelf regelen. Een mislukte overstap hoeft de app zelf niet stil te leggen, maar kan tijdens het drukke retourseizoen de Built for Shopify-status en de klantervaring in gevaar brengen.
Deze gids legt de regel uit, laat zien voor welke apps die geldt, maakt onderscheid tussen retouren en bestellingen bewerken vóór fulfillment, en geeft bureaus een controle in 7 stappen die ze vóór 1 december kunnen uitvoeren.
Wat de Customer Account API-eis voor Built for Shopify verandert
Vanaf 1 december 2026 moeten retour- en ruilapps waarmee klanten zelf acties kunnen uitvoeren de Customer Account API gebruiken als primaire methode voor klantauthenticatie om hun Built for Shopify-status te behouden. Shopify kondigde de wijziging aan op 17 juni 2026. Betrokken appontwikkelaars kregen daarmee ongeveer vijf en een halve maand om over te stappen.
De officiële changelog voor Shopify-ontwikkelaars noemt ook abonnementsapps. Voor teams die retouren beheren, draait het om zelfservice voor klanten: een klant kan zonder hulp van medewerkers een retour starten of beheren, een ruiling volgen of een vergelijkbare actie uitvoeren.
Het gevolg is beperkter dan sommige samenvattingen van de deadline suggereren. Volgens Shopify lopen apps die niet aan de eis voldoen het risico hun Built for Shopify-status te verliezen. Shopify zegt niet dat elke betrokken app stopt met werken, uit de Shopify App Store verdwijnt of precies om middernacht de werkprocessen van merchants uitschakelt.
| Controlevraag | Tot en met 30 november 2026 | Vanaf 1 december 2026 |
|---|---|---|
| Vereiste primaire authenticatie voor klanten | Bestaande methode mag blijven | Customer Account API |
| Betrokken categorieën | Retouren, ruilingen, abonnementen | Dezelfde categorieën |
| Zelfservice voor klanten vereist | Ja, anders is de regel niet van toepassing | Ja, anders is de regel niet van toepassing |
| Direct gevolg dat Shopify noemt | De overstapperiode loopt nog | Built for Shopify-status loopt risico |
| Actie voor de merchant | Vraag de leverancier om bewijs | Controleer hoe de app in productie werkt |
Behandel 1 december als een deadline voor leveranciersbeheer, niet als een datum waarop je webshop automatisch uitvalt. Bureaus moeten de kwestie wel nu al onder de aandacht brengen. Een statuswijziging of haastig uitgebrachte authenticatiewijziging kan tijdens de feestdagenretouren vermijdbare problemen veroorzaken.
Voor welke apps de Built for Shopify-eis geldt
Een app valt onder de eis als drie voorwaarden samenkomen: de app hoort bij de categorie retouren, ruilingen of abonnementen; klanten kunnen er zelf acties mee uitvoeren; en de app wil na 1 december 2026 de Built for Shopify-status behouden. Niet elke app die een merchant gebruikt, valt automatisch onder de regel.
Gebruik deze checklist voor elke app die na aankoop een rol speelt:
- Controleer de appcategorie. Ga na hoe Shopify en de leverancier de app indelen. Leid de categorie niet af uit de naam van een functie.
- Breng de functies voor klanten in kaart. Neem het starten van retouren, het volgen van ruilingen, het aanpassen van abonnementen en elk klantportaal dat hiervoor wordt gebruikt mee.
- Bepaal de huidige authenticatiemethode. Vraag of de Customer Account API van Shopify in productie al de primaire methode is.
- Vraag of de leverancier de Built for Shopify-status wil behouden. Een app zonder badge kan die badge niet verliezen, al kan compatibiliteit met klantaccounts operationeel nog steeds belangrijk zijn.
- Maak onderscheid tussen acties vóór fulfillment en na levering. Een bestelling aanpassen voordat die is afgehandeld, is een bestelling bewerken. Een geleverd product terugsturen is een retour. Klanten kunnen er vergelijkbare woorden voor gebruiken, maar het zijn verschillende processen.
Dat laatste onderscheid voorkomt de meest voorkomende fout bij de controle. Een klant kan een maatcorrectie een “ruiling” noemen, maar als je vóór fulfillment een variant vervangt, is retourlogistiek helemaal niet nodig. Een ruiling na levering vraagt om een retourproces, regels voor ontvangst of inspectie en een vervangende verzending.
Onze dataset laat zien dat bij meer dan 10 miljoen Shopify-bestellingen ongeveer 1 op de 19 (5,2%) na checkout wordt bewerkt (Revize, 2026). Bureaus moeten daarom beide processen controleren, maar de eis van 1 december alleen toewijzen aan de categorieën die Shopify daadwerkelijk noemt.
Wat de Customer Account API precies doet
De Customer Account API authenticeert de klant en geeft een app gecontroleerde toegang tot de Shopify-accountgegevens van die klant. Een API, of programmeerinterface, is een gereguleerde toegang tussen systemen: de app dient een geautoriseerd verzoek in en Shopify geeft alleen de gegevens terug waartoe dat verzoek toegang heeft.
Dit verschilt van de Admin API, waarmee een app doorgaans namens de merchant handelt. Volgens de referentie voor de Customer Account API van Shopify kan de klantgerichte API de eigen gegevens van de klant lezen en bijwerken, waaronder bestellingen, profielen en adressen.
Op 29 augustus 2026 toont de referentie van Shopify 2026-07 als nieuwste versie. De documentatie beschrijft ook discovery-endpoints. Daarmee kan een app voor elke winkel de juiste authenticatie- en GraphQL-endpoints ophalen, in plaats van één domein vast in de code op te nemen.
Authenticatie en de plek waar een interface verschijnt, zijn twee verschillende zaken. Een Customer Account UI extension bepaalt waar een ervaring binnen klantaccounts verschijnt. De Customer Account API regelt geauthenticeerde toegang tot klantgegevens. Een app kan een verzorgde component op de accountpagina hebben, terwijl de leverancier nog moet bevestigen dat de vereiste API de primaire authenticatiemethode is.
Bureaus moeten schriftelijk antwoord vragen op vier technische vragen:
- Wordt de klant in het productieproces geauthenticeerd via de Customer Account API?
- Welke toegangsroutes gebruiken de API, waaronder accountpagina’s, bestel-e-mails, directe links en externe portalen?
- Is de overstap voor elke merchant actief, of alleen voor een testgroep?
- Welk bewijs verschijnt na de beoordeling van de overstap in het Partner Dashboard van de leverancier?
Let op: Accepteer “ondersteunt nieuwe klantaccounts” niet als volledig bewijs. Ondersteuning voor de interface en naleving van de authenticatie-eis hangen samen, maar betekenen niet hetzelfde.
Welke rol Revize speelt bij de controle voor december
Revize biedt klanten zelfservice vóór fulfillment, terwijl de regel van 1 december gericht is op specifieke retour- en ruilapps voor na levering. Shopify vermeldt de app voor bestellingen bewerken momenteel als Built for Shopify en compatibel met klantaccounts. De app valt onder de categorie bestellingen bewerken, niet onder retouren en ruilingen.
Klanten kunnen via het zelfserviceportaal voor bestellingen bewerken vóór fulfillment adressen, varianten, aantallen of in aanmerking komende bestellingen wijzigen. De functie verschijnt op de bestelstatuspagina van Shopify en de merchant bepaalt hoelang klanten hun bestelling kunnen bewerken.
Die afbakening tussen categorieën is waardevol. Als je een bestelling corrigeert voordat die wordt verzonden, voorkom je dat een vermijdbare retour in het retourproces terechtkomt. Retouren na levering blijven een afzonderlijk proces. Een winkel met veel bestellingen kan dus een app voor bestellingen bewerken combineren met een gespecialiseerd retourplatform, zonder dat het ene systeem de rol van het andere moet overnemen.
| Wat de klant nodig heeft | Fase van de bestelling | Geschikt systeem | Relevantie van de regel van 1 december |
|---|---|---|---|
| Verzendadres corrigeren | Vóór fulfillment | App voor bestellingen bewerken | Valt niet alleen op basis van de categorie onder de regel |
| Maat wijzigen vóór verzending | Vóór fulfillment | App voor bestellingen bewerken | Valt niet alleen op basis van de categorie onder de regel |
| Een daarvoor in aanmerking komende bestelling annuleren | Vóór fulfillment | App voor bestellingen bewerken | Valt niet alleen op basis van de categorie onder de regel |
| Geleverd artikel terugsturen | Na fulfillment | Retourapp | Valt onder de regel als klanten dit zelf kunnen doen |
| Vervangende verzending volgen | Tijdens het retour- of ruilproces | Ruilapp | Valt onder de regel als klanten dit zelf kunnen doen |
Voor bureaus die winkels met de abonnementen Plus, Advanced en Grow controleren, is het belangrijk dit onderscheid vast te houden. Laat correcties vóór fulfillment via de app voor bestellingen bewerken lopen en vraag de retourleverancier afzonderlijk om bewijs dat de app aan de eis voldoet. Merken zoals Square Enix, Venchi, Shelly, Nude Project, AYBL en TheGameCollection gebruiken het model van zelfservice voor klanten in verschillende productcategorieën.
Komen verzoeken om adreswijzigingen, variantwissels en annuleringen bij jouw winkel nog bij support terecht? Voeg dan zelfservice vóór fulfillment toe terwijl de retourleverancier de overstap voor december afrondt.
Hoe bureaus de Customer Account API-eis kunnen controleren
Voer deze controle in 7 stappen vóór 1 december 2026 uit voor elke klant met zelfservice voor retouren, ruilingen of abonnementen. Het resultaat moet aantonen hoe elke toegang voor klanten in productie werkt. Alleen vastleggen dat een leverancier een overstap heeft beloofd, is onvoldoende.
- Maak een overzicht van betrokken apps. Noteer voor elke app de Shopify-categorie, Built for Shopify-status, functies voor klanten, zakelijke eigenaar, technische eigenaar en verlengingsdatum. Houd bestellingen bewerken, tracking, retouren, ruilingen, abonnementen, helpdesk en magazijnfuncties apart.
- Vraag om een gedateerde verklaring van de leverancier. Vraag of de app onder de aangekondigde categorie-eis van Shopify valt en of de Customer Account API in productie de primaire authenticatiemethode is. Is het antwoord nog nee, vraag dan om een geplande releasedatum.
- Breng elke toegangsroute voor klanten in kaart. Test navigatie in het account, bestelstatuspagina’s, bevestigingsmails, retourlinks, het volgen van ruilingen, bestemmingen van QR-codes, mobiele browsers en links vanuit headless webshops. Vanuit het hoofdmenu van het account kan authenticatie goed lijken te werken, terwijl een oudere directe link nog een apart portaal opent.
- Controleer wat er bij het aanmelden gebeurt. Kijk wat er gebeurt als de klant al is aangemeld, is afgemeld of via een oude bladwijzer terugkomt. Leg doorverwijzingen, herhaalde inlogverzoeken, verloren bestelcontext en elke route die om aparte inloggegevens voor een portaal vraagt vast.
- Test volledige retour- en ruilprocessen. Gebruik gecontroleerde bestellingen om een retour die is toegestaan, een artikel dat niet retour mag, een gedeeltelijke retour, een ruiling, een annulering en een klant die het proces onderbreekt en later hervat te testen. Controleer de uiteindelijke status in Shopify en in elk gekoppeld operationeel systeem.
- Verzamel bewijs van beide kanten. Bewaar opnames van het klantproces, tijdlijnen van Shopify-bestellingen, releaseopmerkingen van de leverancier, bevestigingen van support en de datum van elke test. Vraag de appontwikkelaar ook om beschikbaar bewijs van de eigen Built for Shopify-beoordeling.
- Maak een plan om wijzigingen terug te draaien en problemen te escaleren. Leg vast wie bij de klant en het bureau verantwoordelijk is, wie de contactpersoon bij de leverancier is, hoe support het proces tijdelijk opvangt en wanneer je beslist over vervanging van een app die geen overtuigend bewijs kan leveren. Plan die beslissing vóór de wijzigingsstops in het drukke seizoen.
Wacht niet met testen tot de badge verandert. De badge zelf veroorzaakt zelden de grootste schade. Die ontstaat als een klant de bestelling niet kan vinden, een ruiling niet kan hervatten of niet begrijpt waarom de vertrouwde route via het account ineens anders werkt.
Wat gaat er na 1 december daadwerkelijk mis?
Het enige gevolg dat Shopify expliciet noemt voor 1 december, is dat een betrokken app die niet aan de eis voldoet het risico loopt de Built for Shopify-status te verliezen. Verdergaande claims, zoals automatische verwijdering uit de Shopify App Store of directe sluiting van retourportalen, gaan verder dan de gepubliceerde aankondiging.
Merchants moeten wel drie praktische risico’s beoordelen:
- Vertrouwen: De app kan een kwaliteitskenmerk verliezen dat merchants gebruiken bij de keuze en beoordeling van apps.
- Nieuwe release: Een late overstap naar een andere authenticatiemethode kan leiden tot inloglussen, kapotte doorverwijzingen of ontbrekende bestelcontext. Controleer dit met testbestellingen; ga er niet bij voorbaat van uit dat het gebeurt.
- Support: Als zelfservice niet betrouwbaar werkt, kunnen klanten tijdens de drukste retourperiode terugvallen op e-mail of chat.
De badge is het middel dat Shopify noemt om de eis te handhaven. Het klantproces is wat de merchant in de praktijk moet testen.
Tip: Bewaar de verklaring van de leverancier en je testbewijs in hetzelfde controledossier. Een datum op een roadmap laat zien wat de leverancier van plan is; een succesvol doorlopen klantproces laat zien dat de app klaar is.
Wat Plus-teams nu moeten doen
Met nog 94 dagen te gaan op 29 augustus moeten bureaus het onderzoek in september afronden, in oktober in productie testen en vóór de wijzigingsstops in november beslissen over oplossingen. De deadline van 1 december is concreet, controleerbaar en beperkt genoeg om te beoordelen zonder alle apps voor processen na aankoop te vervangen.
Doe deze week het volgende:
- Maak een overzicht van elke retour-, ruil- en abonnementsapp waarmee klanten zelf acties kunnen uitvoeren.
- Vraag elke leverancier of authenticatie via de Customer Account API in productie de primaire methode is.
- Test elke toegangsroute voor klanten met gecontroleerde bestellingen.
- Houd bestellingen bewerken vóór fulfillment gescheiden van retouren na levering.
- Leg bewijs, verantwoordelijken, deadlines en een alternatieve route vast.
Het doel is geen overstap voor de vorm. Het doel is één betrouwbare klantidentiteit tijdens het hele traject na aankoop, onderbouwd met bewijs dat je bureau kan laten zien.
Veelgestelde vragen
Deze antwoorden behandelen de 10 vragen die bureaus en Plus-teams vóór 1 december 2026 moeten oplossen. De gepubliceerde regel is beknopt. Maak daarom onderscheid tussen de precieze eis van Shopify en praktische conclusies waarvoor je nog bewijs van de leverancier en testbestellingen nodig hebt.
Wat verandert er op 1 december 2026?
Betrokken retour-, ruil- en abonnementsapps moeten de Customer Account API gebruiken als primaire methode voor klantauthenticatie om hun Built for Shopify-status te behouden. De regel geldt wanneer klanten via de app zelf acties kunnen uitvoeren. Shopify kondigde de deadline aan op 17 juni 2026.
Stopt een retourapp op 1 december met werken?
Shopify heeft niet gezegd dat betrokken apps op 1 december automatisch stoppen met werken. Het gepubliceerde gevolg is dat apps die niet aan de eis voldoen het risico lopen hun Built for Shopify-status te verliezen. Merchants moeten leveranciers vragen of het proces blijft werken en dit daarna met testbestellingen controleren, in plaats van een storing te voorspellen.
Geldt de eis voor elke Shopify-app?
Nee, de aangekondigde eis geldt niet voor elke Shopify-app. Shopify noemt retour- en ruilapps en abonnementsapps waarmee klanten zelf acties kunnen uitvoeren. Verklaar apps voor tracking, helpdesk, bestellingen bewerken, magazijnbeheer en andere categorieën niet van toepassing, tenzij Shopify of de leverancier bewijs levert dat de eis voor die categorie geldt.
Is de merchant verantwoordelijk voor de overstap naar de API?
De appontwikkelaar voert de overstap naar de API uit; de merchant blijft verantwoordelijk voor leveranciersrisico’s en operationele risico’s. Bureaus moeten de productiestatus bij de leverancier opvragen, de betrokken klantprocessen testen en een alternatief vastleggen. Een merchant kan de authenticatiearchitectuur van een externe app niet via instellingen in Shopify Admin aanpassen.
Wat is de Customer Account API?
De Customer Account API is de interface van Shopify voor geauthenticeerde toegang van klanten tot hun accountgegevens. Hiermee kan een app werken met gegevens van de aangemelde klant, zoals bestellingen, profielgegevens en adressen. Shopify positioneert de API als gedeelde authenticatielaag voor klantaccounts, webshops en gekoppelde apps.
Is de API hetzelfde als een Customer Account UI extension?
Nee, authenticatie en de plek waar een interface verschijnt, zijn afzonderlijke zaken. De Customer Account API regelt geauthenticeerde toegang tot gegevens. Customer Account UI extensions tonen appfuncties binnen accountpagina’s van Shopify. Een app kan beide nodig hebben en moet nog steeds aantonen dat de API de primaire authenticatiemethode is.
Moet het hele retourportaal worden verplaatst?
De gepubliceerde regel voor december vereist specifiek dat de Customer Account API de primaire authenticatiemethode is. Er staat niet dat elk scherm opnieuw binnen één Shopify-interface moet worden gebouwd. Bureaus moeten leveranciers vragen welke onderdelen van de interface en achterliggende systemen veranderen en daarna het volledige proces testen, omdat authenticatie elke vervolgstap raakt.
Hoe test je gastbestellingen?
Test gastbestellingen via de echte links en aanmeldsituaties die de leverancier ondersteunt. Neem toegang via bevestigingsmails, afgemelde browsers, verlopen sessies en een volgend bezoek op een ander apparaat mee. Ga er niet van uit dat een geslaagde test met een aangemeld account bewijst dat elke route voor gasten of vóór authenticatie klaar is.
Kan een merchant de huidige retourapp behouden?
Ja, mits de leverancier een geloofwaardig traject kan aantonen waarmee de app aan de eis voldoet en het productieproces de tests doorstaat. De deadline verplicht merchants op zichzelf niet om een app te vervangen. Vervanging wordt een operationele beslissing als de leverancier geen bewijs kan leveren, afgesproken mijlpalen mist of niet slaagt voor gecontroleerde tests van het klantproces.
Welk bewijs moet een bureau bewaren?
Bewaar de verklaring van de leverancier, de testdatum, een opname van het klantproces, de ID’s van betrokken bestellingen, de uiteindelijke statussen in Shopify en de verantwoordelijke voor escalatie. Voeg schermafbeeldingen toe van de huidige Built for Shopify-status van de app en relevant bewijs uit het Partner Dashboard als de leverancier dat kan delen. Het dossier moet laten zien wat daadwerkelijk is waargenomen, niet alleen wat gepland staat.
Verzamel het bewijs nu, laat elk systeem het werk doen waarvoor het bedoeld is en ga 1 december in met een getest klantproces in plaats van een aanname.