Shopify-integrationsprojekter fejler sjældent, fordi API'et ikke kan løfte opgaven. De fejler som regel, fordi ejerskabet er uklart, payloads er overdesignede, og fejlhåndtering bliver behandlet som en eftertanke.
Derfor er det vigtigste arkitekturspørgsmål ikke "Hvordan forbinder vi Shopify til ERP og PIM?", men "Hvilket system ejer hvilken sandhed, og hvordan bevæger ændringer sig gennem it-landskabet uden at skabe synkroniseringsgæld?"
Shopifys egen platformsretning peger i samme retning. REST Admin API er nu dokumenteret som et legacy-API siden den 1. oktober 2024, og Shopifys anbefaling er klar: nye integrationer skal bygges med GraphQL Admin API. Shopify anbefaler fortsat webhooks til hændelsesdrevne opdateringer, men understreger samtidig, at apps ikke bør basere sig udelukkende på webhooks og bør inkludere reconciliation-mønstre.
Denne artikel beskriver en praktisk integrationsmodel for 2026: GraphQL som standard, webhooks som en del af løsningen frem for hele løsningen, brug af bulk-operationer, og en arkitektur styret af systemejerskab frem for bekvemmelighed.
Det vigtigste at tage med
- Den reneste Shopify-integrationsarkitektur starter med regler for ejerskab, ikke med API-endpoints.
- Shopifys nuværende anbefaling er GraphQL som standard. REST Admin API er legacy og bør ikke være udgangspunktet for nyt arbejde.
- Webhooks bør udløse behandling, men bør ikke være den eneste kilde til sandhed.
- Bulk-operationer er nu et centralt mønster til tilbagemigrering, store eksporter og reconciliation i stor skala.
- Shopify, ERP og PIM bør hver især eje de domæner, hvor de skaber operationel klarhed, frem for at dele kontrollen.
Start med systemejerskab
En ren arkitektur giver som regel hver platform én primær rolle.
Shopify ejer typisk
- Produktmerchandising, som vises i webshoppen
- Kurve, checkout-kontekst og ordreindgang
- Præsentationen i den online webshop
- Kundevendte kampagner og forretningsregler, der afhænger af Shopifys egen adfærd
ERP'et ejer typisk
- Den finansielle sandhed
- Lagerregnskabet
- Indkøb, genbestilling og styring af opfyldelse, hvor bredere virksomhedslogik indgår
- Skat, fakturering og driftsrapportering, der skal stemme overens med finansprocesserne
PIM'en ejer typisk
- Struktureret produktindhold
- Berigelsesworkflows
- Styring af attributter
- Regler for kanaldistribution af produktdata ud over én webshop
Formålet med modellen er ikke stivhed. Det er at forebygge konflikter. Når flere systemer kan overskrive de samme felter uden en klar prioritering, bliver fejlfinding langsommere, og datakvalitet bliver en intern forhandlingssag.
Brug GraphQL som standard for integrationer
Shopifys nuværende API-dokumentation siger, at REST Admin API er legacy, og at alle apps og integrationer bør bygges med GraphQL Admin API. Det skift handler ikke kun om fremtidssikring. GraphQL er ofte også den bedre operationelle løsning, fordi integrationsteams kan hente præcis de felter, de har brug for, og udvikle payloads mere målrettet.
I praksis giver en GraphQL-først-tilgang som regel renere feltvalg, mindre overhentning af data, bedre overensstemmelse med Shopifys nuværende platformsretning, samt stærkere understøttelse af bulk-operationer og skemadrevet udvikling.
Det kræver ikke en fuld omskrivning fra dag ét, hvis der stadig findes gamle REST-flows. Det betyder derimod, at nyt integrationsarbejde bør undgå at gøre afhængigheden af REST endnu dybere.
Brug webhooks som udløsere, ikke som hele integrationsstrategien
Shopifys anbefalinger til webhooks er usædvanligt direkte: apps bør ikke udelukkende basere sig på at modtage data fra webhooks. Det er lige så god rådgivning for arkitekturen omkring ERP og PIM.
Webhooks er gode til at signalere hændelser. De er mindre pålidelige som eneste garanti for, at to systemer forbliver synkroniserede for evigt. Forsinkelser, genforsøg, rate limits, nedbrud i middleware og delvise fejl sker.
Et stærkere mønster er at bruge webhooks til at udløse den efterfølgende behandling, hente den seneste nødvendige tilstand via API'et inden kritiske opdateringer, og køre planlagt reconciliation for kritiske enheder som produkter, lager, priser, kunder og ordrer. Den tilgang reducerer risikoen for stille afdrift i dataene.
Brug bulk-operationer til tilbagemigrering og reconciliation
Bulk-operationer er nu et af de vigtigste redskaber i Shopifys integrationsmodel. Shopifys guide til GraphQL bulk-operationer forklarer, at bulk-forespørgsler henter store datamængder asynkront og reducerer behovet for paginering i klienten.
Det betyder noget i tre almindelige situationer: ved indledende migrering eller tilbagemigrering ved en replatforming, ved periodisk reconciliation af kataloger eller ordrer, og ved gendannelse efter fejl i middleware eller webhooks.
Som tjekket den 11. maj 2026 dokumenterer Shopify, at apps, der bruger API-version 2026-01 eller nyere, kan køre op til fem bulk-forespørgsler ad gangen pr. butik. Det er en markant forbedring i skalerbarheden, men kræver stadig driftsmæssige rammer omkring kø, filhåndtering og genforsøgslogik.
Design til versionering fra starten
Shopifys model for API-versionering er datobaseret, og udfasninger annonceres gennem dokumentationen og udvikler-changeloggen. Det betyder, at versionsstyring bør behandles som et løbende driftsansvar, ikke som en engangsopgave i byggefasen.
En fornuftig driftsrytme omfatter typisk fastlåsning af API-versioner, kvartalsvis gennemgang af relevante punkter i changeloggen, plads i backloggen til opgraderinger ved udfasninger, samt overvågning af felter eller ressourcer, der er markeret som legacy.
Det er særligt vigtigt i blandede miljøer, hvor gammel REST-logik stadig ligger side om side med nyere GraphQL-flows.
Anbefalet integrationsmønster
For mange mellemstore og store Shopify-miljøer fungerer følgende mønster godt.
Produktdata
PIM'en ejer det strukturerede produktindhold. Godkendte data strømmer ind i Shopify via en GraphQL-drevet tjeneste til produktpublicering. Shopify ejer derefter præsentationen i webshoppen, merchandising-konteksten og eksponeringen på salgskanalerne.
Ordrer og kunder
Shopify fanger selve handelshændelsen. Integrationslaget sender derefter valideret ordre- og kundedata videre til ERP'et, som bliver det finansielle og operationelle bogholderi, hvor det er relevant.
Lager
ERP'et forbliver kilden til sandheden om lagerbeholdning, hvor der er kompleks lagerlogik i virksomheden. Shopify modtager lageropdateringer ofte nok til at understøtte præcist salg, mens reconciliation-jobs beskytter mod afdrift.
Undtagelser
Et kø- eller middleware-lag gemmer status for genforsøg, korrelations-id'er og fejllogs, så fejl kan afspilles igen uden manuel datareparation.
Almindelige fejl
Tre fejl går igen. For det første flyttes for meget logik ind i Shopify, fordi det er hurtigt at implementere der. Det kan skabe skrøbelig dobbeltarbejde, når ERP'et eller PIM'en stadig ejer den samme proces. For det andet behandler teams webhooks, som var de et permanent revisionsspor. Det er de ikke. For det tredje får integrationspayloads lov til at vokse uden disciplin omkring ejerskab. Når hver eneste nedstrøms-forbruger vil have alle felter hver gang, bliver miljøet dyrt at vedligeholde og svært at teste.
Praktisk tjekliste
Gennemgå følgende, før integrationsarkitekturen låses fast:
- Fastlæg ejerskab på feltniveau for produkt, pris, lager, ordre og kunde
- Lad nyt arbejde som standard bruge GraphQL Admin API frem for at gøre REST-afhængigheden dybere
- Brug webhooks som udløsere, og tilføj planlagt reconciliation for kritiske enheder
- Planlæg bulk-operationer til tilbagemigrering, gendannelse og validering i stor skala
- Fastlås API-versioner, og planlæg tilbagevendende gennemgange af changeloggen
- Bevar data om genforsøg og sporbarhed i middleware
- Test fejlscenarier, ikke kun den optimale synkronisering
Ofte stillede spørgsmål
Bør Shopify eller ERP'et eje lagerstyringen?
I de fleste større setup bør ERP'et forblive den driftsmæssige autoritet på lager, mens Shopify opdateres ofte nok til at kunne sælge præcist.
Er REST stadig acceptabelt til eksisterende integrationer?
Eksisterende flows kan godt fortsætte, men Shopify dokumenterer REST Admin API som legacy. Nyt integrationsarbejde bør som udgangspunkt være GraphQL-først.
Er webhooks nok til pålidelig synkronisering?
Nej. Shopifys egne anbefalinger siger, at apps ikke bør basere sig udelukkende på webhooks, og at der bør indgå reconciliation-mønstre.
Hvornår er bulk-operationer besværet værd?
De er særligt nyttige til store katalogeksporter, tilbagemigrering af ordrehistorik og periodisk reconciliation i stor skala.
Konklusion
God Shopify-integrationsarkitektur er først og fremmest en styringsdisciplin. GraphQL, webhooks og bulk-operationer er vigtige, men de virker kun rent, når ejerskab, genforsøg og reconciliation er designet fra starten.
Det er som regel forskellen på et integrationsmiljø, der kan skalere, og et der stille og roligt opbygger driftsgæld.
