Shopify + Alumio: multi-channel integraties centraliseren

Shopify + Alumio: multi-channel integraties centraliseren

Een Shopify Plus winkel die op vier kanalen verkoopt, draait al snel op zeven losse koppelingen. Webshop naar ERP. ERP naar WMS. Marktplaats naar voorraad. Boekhouding naar orders. Elke koppeling een eigen scriptje, een eigen foutmelding, een eigen persoon die "er even naar kijkt".

Dat werkt tot het niet meer werkt. Bij één van onze klanten viel de voorraadsync naar bol.com 's nachts stil. Resultaat: 40 oververkochte orders voor het ontbijt. De koppeling was niet kapot. Hij liep tegen een rate limit aan en had geen retry-mechanisme.

Met een iPaaS zoals Alumio los je dat structureel op. Niet door meer scripts, maar door één centrale laag tussen al je systemen.

Het probleem met point-to-point koppelingen

Point-to-point betekent: elk systeem praat rechtstreeks met elk ander systeem. Bij twee systemen heb je één koppeling. Bij vijf systemen kunnen het er tien zijn.

Die complexiteit groeit kwadratisch. En elke koppeling heeft zijn eigen:

• Datamapping (Shopify noemt het variant, je ERP noemt het artikel)
• Foutafhandeling (of het ontbreken daarvan)
• Authenticatie en tokens die verlopen
• Logging die nergens samenkomt

Wij zien bij klanten dat niemand nog overzicht heeft. Een order mislukt en de zoektocht begint: zit het in Shopify, in de middleware, in het ERP? Drie systemen, drie logfiles, drie inloggegevens.

Een iPaaS draait dat om. Alle systemen praten met één hub. Die hub heeft één logboek, één retry-strategie en één plek waar je mappings beheert.

Eén bron van waarheid: waar ligt die echt?

"Single source of truth" klinkt mooi, maar de vraag is: welk systeem is de baas over welke data?

Dat moet je expliciet maken. Per dataobject één eigenaar:

Alumio dwingt deze keuze niet af, maar maakt hem zichtbaar. Je ziet per flow waar data vandaan komt en waar hij heen gaat. Geen impliciete aannames meer in een vergeten cron job.

De winst: als voorraad ergens niet klopt, weet je meteen waar je moet kijken. Het ERP heeft gelijk, de rest is een afgeleide.

Voorraad over meerdere kanalen synchroniseren

Voorraad is waar het misgaat bij multi-channel. Je verkoopt hetzelfde product op Shopify, bol.com en Amazon. Eén voorraadpot, drie kanalen die eraan trekken.

Zonder centrale sync krijg je oververkoop. Iemand koopt het laatste stuk op Amazon, maar Shopify weet dat pas vijf minuten later. In die vijf minuten verkoop je hetzelfde stuk nog drie keer.

Met Alumio loopt voorraad via één flow:

1. WMS of ERP meldt een mutatie (verkoop, retour, bijbestelling)
2. Alumio ontvangt de update via webhook of polling
3. Alumio verdeelt de actuele voorraad over alle kanalen
4. Elk kanaal krijgt het juiste aantal, eventueel met buffer

Die buffer is belangrijk. Wij adviseren klanten vaak om per kanaal een veiligheidsmarge in te bouwen. Verkoop je 3 stuks, toon dan 0 op het kanaal zodra de echte voorraad onder de marge zakt. Beter een gemiste sale dan een geannuleerde order met een boze klant en een marktplaats-penalty.

Let ook op timing. Een full sync van 50.000 SKU's elke vijf minuten is verspilling en jaagt je rate limits erdoorheen. Wij schakelen daarom over op delta sync: alleen muteren wat veranderd is. Een verkoop triggert direct een update van dat ene artikel. Een nachtelijke full sync corrigeert eventuele afwijkingen. Het beste van beide: realtime waar het moet, volledigheid waar het kan.

Een concreet voorbeeld. Een klant van ons verkoopt 8.000 SKU's op Shopify, bol.com en een eigen B2B-portaal. Voorheen draaide elke koppeling zijn eigen voorraadexport, drie keer per dag. Afwijkingen tussen kanalen liepen op tot honderden stuks. Na de overstap naar één Alumio-flow met delta sync zakte het verschil naar bijna nul, en daalde het aantal handmatige correcties van tientallen per week naar een handvol per maand.

Rate limits: het stille struikelblok

Shopify's Admin API werkt met een leaky bucket. Je krijgt een bucket van 40 requests (REST) of een puntenbudget (GraphQL), die langzaam weer bijvult. Ga je te snel, dan krijg je een 429 Too Many Requests.

Marktplaatsen hebben hun eigen limieten. bol.com, Amazon SP-API, elk met andere quota en andere strafmaatregelen bij overschrijding.

Een zelfgebouwd script negeert dit meestal. Het vuurt requests af tot het stukloopt. Dan staat de sync stil en weet niemand het.

Alumio vangt dit op met:

• Throttling — requests worden gedoseerd binnen het toegestane budget
• Retry met backoff — bij een 429 wacht het systeem en probeert opnieuw, met oplopende intervallen
• Queueing — pieken worden afgevlakt; berichten staan in een queue en worden in tempo verwerkt
• Dead letter handling — wat na X pogingen niet lukt, komt apart te staan voor inspectie

Het verschil in de praktijk: een Black Friday-piek die een eigen koppeling onderuithaalt, wordt door de queue rustig afgewikkeld. Trager misschien, maar zonder dataverlies.

Nog een detail dat vaak vergeten wordt: idempotentie. Als een retry hetzelfde order-bericht nogmaals verstuurt, mag dat geen dubbele order in je ERP veroorzaken. Alumio werkt met unieke identifiers per bericht, zodat een herhaalde poging niet leidt tot dubbele data. Bij een zelfgebouwd script moet je dit zelf bedenken en bouwen, en in de praktijk gebeurt dat zelden goed.

Orders en ERP: de retourstroom

Een order in Shopify is pas klaar als hij verwerkt is in je ERP en je boekhouding. Die keten moet kloppen, ook als er onderweg iets misgaat.

Een typische orderflow via Alumio:

Shopify order created
  → Alumio (transform: order → ERP-formaat)
    → ERP (order aangemaakt)
      → WMS (pickopdracht)
        → Shopify (fulfillment + tracking terug)
          → klant (verzendmail)

Het cruciale deel zit aan het eind: de status moet terug. Verzonden, geannuleerd, deels geleverd. Als die terugkoppeling ontbreekt, mailt Shopify geen tracking en bellen klanten je klantenservice plat.

Alumio houdt per stap de status bij. Mislukt de ERP-stap, dan blijft het bericht in de queue en blokkeert het de rest niet. Je ziet in één dashboard welke orders vastlopen en waarom.

Werkt jouw ERP met een eigenzinnig formaat of een SOAP-API uit 2009? Dat is precies waar de transformatielaag van een iPaaS zijn waarde bewijst. Wij hebben dit soort koppelingen gebouwd voor uiteenlopende systemen — neem contact op als je wilt sparren over jouw specifieke stack.

Wanneer Alumio NIET de juiste keuze is

Eerlijk verhaal: een iPaaS is niet gratis en niet altijd nodig.

Heb je één webshop en één boekhouding? Dan is een kant-en-klare app uit de Shopify App Store goedkoper en sneller live. Een iPaaS is overkill.

Verkoop je op één kanaal met een paar honderd orders per maand? Dan weegt de licentiekost niet op tegen de winst.

Alumio gaat lonen vanaf het moment dat je:

• Op drie of meer kanalen verkoopt
• Een ERP of WMS hebt dat niet standaard met Shopify praat
• Tegen rate limits of timing-problemen aanloopt
• Foutopsporing over meerdere systemen kwijt bent

Twijfel je tussen iPaaS en een custom integratie? Custom kan goedkoper zijn bij één simpele, stabiele koppeling. Bij groei en meerdere systemen wint de centrale laag bijna altijd op onderhoudbaarheid.

De rol van de developer blijft

Een iPaaS is geen no-code wondermiddel. Je hebt nog steeds iemand nodig die de datamodellen begrijpt en de transformaties goed inricht.

Wat verandert: die developer bouwt niet langer zeven losse scripts die niemand anders snapt. Hij configureert flows in een omgeving waar logging, monitoring en retry al ingebakken zitten.

Wij bouwen deze integraties als Alumio-partner samen met Sinsou, zodat je zowel de Shopify-kant als de integratielaag uit één hand krijgt. Voor maatwerk dat buiten standaard connectoren valt, schrijven we de logica in Laravel en koppelen die aan Alumio.

Het doel is altijd hetzelfde: minder brandjes blussen, meer overzicht. Een order die mislukt mag geen detectivewerk worden.

Praktisch betekent dit ook dat je niet meer afhankelijk bent van één persoon die "de koppeling kent". De flows staan gedocumenteerd in de iPaaS, met logging die iedereen in het team kan lezen. Valt er iemand uit, dan ligt de kennis niet bij hem op een lokale machine maar in een omgeving die het hele team begrijpt. Dat verlaagt het risico bij groei net zo hard als de technische voordelen.

Veelgestelde vragen

Wat kost Alumio voor een Shopify Plus winkel?

Alumio werkt met een licentiemodel op basis van het aantal connectoren en het datavolume. Reken op een maandelijkse fee die los staat van de bouwkosten. Bij drie of meer kanalen verdient die fee zich meestal terug in bespaarde developmenturen en voorkomen oververkoop. Voor een exacte inschatting kijken we naar jouw systemen en volumes.

Vangt Alumio Shopify's rate limits automatisch op?

Ja. Alumio doseert requests binnen Shopify's leaky bucket en doet automatisch retries met backoff bij een 429. Berichten lopen via een queue, zodat pieken worden afgevlakt in plaats van de koppeling stuk te maken. Dit is een van de grootste verschillen met een zelfgebouwd script.

Kan ik bol.com en Amazon koppelen via Alumio?

Ja. Marktplaatsen koppel je als extra kanalen aan dezelfde centrale voorraad- en orderflow. Voorraad wordt over alle kanalen verdeeld vanuit één bron, en orders van marktplaatsen lopen via dezelfde keten naar je ERP. Elk kanaal houdt zijn eigen rate limits en formaateisen, die Alumio per connector afhandelt.

Hoe lang duurt een Shopify-Alumio implementatie?

Dat hangt af van het aantal systemen en de complexiteit van je ERP. Een eenvoudige order- en voorraadkoppeling staat binnen enkele weken. Een traject met een eigenzinnig ERP, meerdere marktplaatsen en custom transformaties duurt langer. We werken in fases: eerst de kritieke flow live, daarna uitbreiden.

Wat gebeurt er als een koppeling toch faalt?

Mislukte berichten blijven in de queue en worden na een wachttijd opnieuw geprobeerd. Lukt het na meerdere pogingen niet, dan komt het bericht in een dead letter queue voor handmatige inspectie. Je ziet in één dashboard wat er vastloopt en waarom, zonder drie systemen langs te moeten.