Koppelingen

Een koppeling verbindt de hub met één systeem: je shop, je ERP, je WMS (magazijnsysteem). Je legt de inloggegevens vast, geeft hem een rol, en zet per soort gegeven aan wat er heen en weer mag. Alles staat op Koppel → Koppelingen & sync.

Eén kaart per systeem, met de entiteiten die aan staan.

1Maak de koppeling

+ Koppeling toevoegen: naam, systeem, rol en omgeving (Productie of Sandbox).

Rol	Betekent
Bron	De hub haalt hier gegevens op
Doel	De hub stuurt hier gegevens heen
Bron & doel	Allebei, per entiteit ingesteld

Op het tabblad Instellingen vul je de gegevens in en druk je op Koppeling testen. Inloggegevens worden versleuteld opgeslagen. Een rode melding betekent bijna altijd dat de API-gebruiker een recht mist, niet dat er iets stuk is: de melding noemt welk endpoint weigerde.

Op hetzelfde tabblad staan ook het blok Type koppeling (de rol later wijzigen; smaller maken zet de sync-units in de andere richting uit, zonder iets te verwijderen) en, bij een doel, Persoonsgegevens anonimiseren. Op de lijst Koppelingen staan per koppeling alleen de schakelaar aan/uit, Koppeling testen en de knop naar de koppeling zelf.

In welke tijdzone stuurt dit systeem tijden?

Veel systemen sturen een tijd zonder tijdzone mee (2026-10-01 01:00:27). Nexym moet dan weten in welke tijdzone die tijd bedoeld is, en rekent hem om naar de tijd die je overal in Nexym ziet.

• Magento, Shopify en WooCommerce: dat staat vast, je hoeft niets te kiezen. Bij Instellingen staat bijvoorbeeld Magento 2 stuurt tijden altijd in UTC — Nexym rekent ze om naar Europe/Amsterdam.
• Andere systemen (een ERP, een bestand, een feed): kies het zelf. Kijk naar een order die je net plaatste: staat de tijd in de bron 2 uur eerder dan op je klok (in de winter 1 uur), kies dan UTC. Onder de keuze zie je je laatst geïmporteerde order: zoals hij nu is opgeslagen, en hoe hij met UTC zou staan. Bij een bestand (SFTP of een URL) geldt de keuze voor elke kolom die je op een tijd koppelt, zoals Besteld op. Een kolom met alleen een datum (2026-10-01) blijft altijd die datum.

Staat een koppeling op een andere tijdzone dan het systeem stuurt, dan zie je een waarschuwing op de koppeling, bijvoorbeeld Deze koppeling staat op Europe/Amsterdam, maar Magento 2 stuurt UTC — tijden staan 2 uur te vroeg, met de knop Zet op UTC. Nexym verandert dat nooit zelf. Na de knop lezen nieuwe imports de tijden goed; orders die al binnen zijn, houden hun tijd tot ze opnieuw worden geïmporteerd.

2Zet aan wat er heen en weer gaat

Op Wat synchroniseren staan twee secties: Import — IN en Export — OUT. Per regel zet je de schakelaar in de kolom Aan om, en kies je een schema.

Opmerking

Richting is altijd vanuit de hub gezien. IN haalt op naar de hub, OUT stuurt vanuit de hub weg. Een order die uit je shop komt is dus orders IN bij de shop en orders OUT bij je ERP.

Een bestand als bron: wat elke kolom is

Bij een bestandskoppeling (SFTP-dropbox of een URL-feed) open je per entiteit het venster Bestand van …. Na Velden ontdekken staat onder Wat elke kolom is elke kolom van je bestand, met een keuzelijst ernaast: een hubveld (Name, Brand name, Main image …) of — voor niet importeren.

Bij producten kan een kolom ook een productattribuut worden. Handig voor kolommen als kleur, inhoud of type_boiler, waar de hub geen eigen veld voor heeft:

Keuze	Wat er gebeurt
Een attribuut onder Productattributen	De kolom vult dat bestaande attribuut
+ Nieuw attribuut: Kleur (kleur)	Bij opslaan maakt Nexym het attribuut kleur aan (type tekst, label Kleur) en koppelt de kolom eraan
+ Nieuw attribuut met een eigen code…	Typ zelf de code, bijvoorbeeld product_soort: alleen kleine letters, cijfers en _

• Bestaat er al een attribuut met die code, dan gebruikt Nexym dat. Er komt nooit een tweede.
• Heet een kolom zoals een bestaand attribuut (de code of de naam, hoofdletters, accenten en spaties maken niet uit), dan staat dat attribuut al voorgeselecteerd met Voorstel. Het wordt pas bewaard als je Bestandsinstellingen opslaan klikt.
• Bij de import komt de waarde op het product als dat attribuut, net als een attribuut uit Magento of een andere koppeling. Een lege cel schrijft niets. Heeft het attribuut een vaste lijst (keuzelijst), dan wordt een naam uit die lijst (Large) de waarde van die optie.
• Een wijziging die je in Nexym aan het attribuut maakte, blijft staan tot ze verstuurd is, zoals bij elk ander veld.

Daarna beheer je de koppeling op Veldkoppeling: daar staat de kolom als rij, met het attribuut onder Productattributen en een voorbeeldwaarde in Example. Ook daar kies je bij een kolom + Nieuw attribuut: Kleur (kleur); het attribuut wordt bij Opslaan aangemaakt. Kies je in Bestand van … een ander antwoord voor een kolom, dan vervalt het oude: de kolom vult daarna alleen nog wat je net koos. Bij orders en andere entiteiten kies je voor zo’n kolom een eigen veld van je project onder Custom fields.

Eigen units: een ander endpoint van hetzelfde systeem

Heeft je systeem een endpoint dat geen enkele standaardkoppeling kent, bijvoorbeeld een module voor bezorgmomenten of reserveringen, dan voeg je het toe onder Eigen units op Wat synchroniseren, met Eigen unit toevoegen. Hij gebruikt het adres en de login van de koppeling; een andere host wordt nooit aangeroepen.

• Verzoek: het pad (alleen lezen), vaste parameters, waar de lijst in het antwoord staat, pagina’s (paginanummer, offset, cursor of searchCriteria) en hoe hij om “gewijzigd sinds” vraagt.
• Koppelen: welk veld het id is, welk veld de hub-referentie, en of hij alleen bijwerkt wat de hub heeft of ook nieuwe records maakt.
• Per record: een detail-verzoek (velden lees je als detail.<veld>) en een verzoek waarvan elk element een regel wordt. Zet {id} waar het id komt.
• Opslaan en voorbeeld ophalen toont elk veld uit het antwoord; de mapping biedt ze aan.
• Eigen velden: maak een veld voor een waarde waar de hub nog geen plek voor heeft (label en soort). Het staat daarna in mapping, regels, lijsten en exports.

Elke eigen unit heeft zijn eigen Mapping, Regels en Schema & runs, en begint uit: de eerste sync start je zelf. Orders uit een eigen unit tellen niet als verkoop (omzet, bestedingen, reviewuitnodigingen) tenzij Telt als verkoop aan staat. Offertes uit een eigen unit staan alleen-lezen in de lijst Offertes. Elk record krijgt source_unit mee, zodat je ze kunt filteren.

3Start de eerste sync

Incrementeel is de standaard; volledige sync alleen handmatig via het tabblad Volledige sync, met bevestiging. Geplande runs, webhooks en Nu uitvoeren lezen bij een import alleen wat sinds de vorige run veranderde, en versturen bij een export alleen wat veranderde. Nexym start nooit zelf een volledige sync.

De eerste sync van een regel is wel een volledige: er is nog niets om vanaf verder te lezen, en een export biedt alles aan wat hij nog nooit verstuurde. Een regel die je net aanzette staat daarom op wacht op de eerste sync tot je hem zelf start: tabblad Volledige sync → Eerste sync starten…. Een import pakt dan de eerste 30 dagen (instelbaar per regel); daarna gaat elke run verder waar de vorige stopte.

Elke run alles ophalen

Sommige bronnen melden een voorraadwijziging niet als wijziging: een gewone run ziet die dan niet. Voor zo’n import-regel zet je bij het potlood (bijvoorbeeld Voorraad · IN) Elke run alles ophalen (niet alleen wijzigingen) aan. Standaard staat het uit.

• Elke geplande run leest dan de hele bron voor die regel, pagina voor pagina en binnen de limieten van het systeem. Hij loopt apart van de korte runs, zodat die niet hoeven te wachten.
• De hub schrijft nog steeds alleen wat verschilt. Een record dat gelijk bleef wordt niet aangeraakt en gaat er niet door opnieuw uit naar een ander systeem.
• Ontbreekt een record in de bron, dan verwijdert de hub het niet.
• In Runs & logs staat bij zo’n run Read everything (setting).

Meestal is dit alleen nodig voor voorraad. Voor andere gegevens kost het veel tijd en API-verzoeken; daar vraagt het venster je eerst Ik begrijp dat elke run de hele bron leest aan te vinken. Leest een koppeling een entiteit al bij elke run volledig, omdat de bron geen “gewijzigd sinds” kent, dan staat dat in het venster en is er niets aan te zetten. De eerste sync van een regel start je nog steeds zelf, op Volledige sync.

Alleen ingeschakelde producten of producten op voorraad importeren

Bij een webshop als bron (Magento, Shopify, WooCommerce) staan bij het potlood van Producten · IN twee vinkjes. Ze staan los van elkaar: zet er één aan, allebei, of geen.

• Alleen ingeschakelde producten importeren: een product dat nog niet in Nexym staat, komt alleen binnen als het in de shop aan staat: in Magento ingeschakeld, in Shopify active, in WooCommerce gepubliceerd.
• Alleen producten op voorraad importeren (nabestellen telt als op voorraad): een product dat nog niet in Nexym staat, komt alleen binnen als het op voorraad is. Staat alleen dit vinkje aan, dan komt een uitgeschakeld product dat op voorraad is wel binnen; het staat in Nexym dan offline.

Een nieuw product moet door elk vinkje dat aan staat. Wat al in Nexym staat, wordt altijd bijgewerkt en nooit verwijderd; varianten van een configureerbaar product komen altijd mee. Minder producten maakt de import sneller en lichter. Een product dat later uit gaat, gaat in Nexym offline. Bij de eerste en een volledige import vraagt Nexym de shop meteen alleen ingeschakelde producten (als dat vinkje aan staat); een gewone run leest alles wat veranderde, zodat ook een product dat uit ging wordt bijgewerkt.

	Magento	Shopify	WooCommerce
Ingeschakeld	status Enabled	status active	status publish
Op voorraad	voorraadstatus (MSI of per product)	een variant met voorraad, met verder verkopen bij geen voorraad, of zonder voorraadbeheer	Op voorraad of Nabestelling
Standaard bij een nieuwe koppeling	beide aan	alleen ingeschakeld aan	alleen ingeschakeld aan
Weer op voorraad	opgehaald na de voorraadimport	bij de volgende wijziging van het product, of een volledige import	bij de volgende wijziging van het product, of een volledige import

Een koppeling die er al was, houdt haar gedrag: alles importeren, tot je een vinkje aanzet. Stond Alleen verkoopbare producten importeren al aan, dan staan nu beide vinkjes aan. Haal je producten uit een ERP of een bestand, dan staan deze vinkjes er niet; sla daar producten over met een Exclude-regel op Online of Status (zie Veldmapping en regels).

Contacten uit je e-mailplatform importeren

Spotler Mailplus, Mailchimp en Klaviyo sturen niet alleen contacten weg (Contacten · OUT), ze lezen ook terug wie ingeschreven is (Contacten · IN). De import haalt alleen het e-mailadres en de inschrijving op, niets anders. Het e-mailplatform is de plek waar mensen zich in- en uitschrijven, dus Nexym neemt daar de inschrijving over:

• De nieuwste keuze van de persoon wint. Wat het platform zegt, ingeschreven of uitgeschreven, wordt de status in Nexym, tenzij de persoon daarna zelf iets anders koos. Een shop zegt vaak “niet ingeschreven” over klanten die het vinkje nooit zagen; dat schrijft niemand uit.
• Een uitschrijving in het platform wordt overgenomen, tenzij de persoon zich daarna opnieuw aanmeldde via een popup, de chat of je shop. Die nieuwere aanmelding blijft staan, en Nexym stuurt haar ook naar het platform, zodat de persoon daar weer mail krijgt:
  • Klaviyo: de persoon wordt weer ingeschreven (staat dubbele opt-in aan, dan eerst met een bevestigingsmail).
  • Mailchimp: Mailchimp stuurt de persoon een bevestigingsmail; pas na de klik is de persoon daar weer ingeschreven. Tot dan staat bij het contact wacht op bevestiging.
  • Spotler Mailplus: Nexym gebruikt de inschrijfaanroep van Spotler. Of Spotler een eerdere afmelding daarmee opheft, is niet zeker; weigert Spotler, dan zie je dat. Zolang het platform de persoon nog niet als ingeschreven terugmeldt, staat bij het contact Opnieuw ingeschreven in Nexym, nog afgemeld in …, en op Wat synchroniseren het aantal.
• Een aanpassing van de status in Nexym zelf schrijft niemand opnieuw in bij het platform.
• Schrijft iemand zich in je shop uit (eerst ingeschreven, nu niet meer), dan blijft die uitschrijving in Nexym staan.
• Contacten die je shop nooit had, komen ook binnen. Ze zijn alleen aan een klant gekoppeld als het adres van een klant is. Een adres dat al in Nexym staat, blijft één contact, ook als het anders gespeld is (hoofdletters).
• Een contact zonder antwoord over toestemming (bijvoorbeeld nog niet bevestigd) komt niet binnen en verandert niets.

Bij Mailchimp leest de import het publiek uit Default audience/list id op het tabblad Instellingen. De eerste sync start je zelf, op Volledige sync; daarna haalt elke run alleen op wat veranderde.

Heb je de koppeling eerder als Doel aangemaakt? Dan staat er op Wat synchroniseren een melding. Zet de rol op Instellingen op Bron & doel, dan verschijnt Contacten onder Import — IN.

4Volledige sync: het enige tabblad voor alles-in-één-keer

Op het tabblad Volledige sync staan alle regels die aan staan, import en export, met per regel wanneer en door wie de laatste volledige sync is gestart.

Regel	Knop	Wat het doet
Import	Historie ophalen…	Haalt een periode op die je kiest — Van een datum Tot en met een datum — in brokken, terwijl de gewone sync doorloopt. Alles ophalen gaat helemaal terug, tot nu.
Import	Volledige import…	Leest alles opnieuw in en schrijft het over wat de hub heeft. Haalt ook de vertalingen per store view op als je koppeling die aangevinkt heeft.
Import (producten)	Lege velden aanvullen…	Leest alleen de producten opnieuw waarbij een veld dat de koppeling levert nog leeg is, 100 per verzoek. Verstuurt niets. Staat er alleen als er zulke producten zijn.
Export	Basislijn opnieuw inlezen…	Leest het doelsysteem en legt per gekoppeld record vast wat daar staat. Verstuurt niets. Aanbevolen als een export uit de pas lijkt te lopen.
Export	Alles opnieuw versturen…	Stuurt elk record opnieuw, compleet, ook wat al verstuurd was.

Elke knop behalve Basislijn opnieuw inlezen en Lege velden aanvullen kan gegevens overschrijven — in je winkel of in de hub — en vraagt daarom om bevestiging. Het venster zegt hoeveel records het raakt, met een rode waarschuwing (Dit kan alles in je winkel overschrijven … Op eigen risico.). De knop Starten werkt pas als je Ik begrijp het aanvinkt én de naam van de koppeling exact typt. De server controleert dat opnieuw, en elke volledige sync komt in het auditlog met wie, wat en hoeveel.

Lege velden aanvullen

Gaat een koppeling later een veld leveren (bij Magento bijvoorbeeld Websites), dan komt dat veld alleen binnen bij producten die daarna in de bron veranderen. Een gewone sync leest alleen wijzigingen, dus producten die sindsdien niet zijn aangepast houden het veld leeg — en wat ervan afhangt ook, zoals Beschikbaar op.

Is dat zo, dan staat boven de tabel een melding, bijvoorbeeld 42.978 producten missen velden die deze koppeling levert: Websites (en daardoor Beschikbaar op). Met Lege velden aanvullen (in de melding of bij Producten · IN) leest Nexym alleen die producten opnieuw, op SKU, 100 per verzoek, op de achtergrond:

• Het venster zegt hoeveel producten het zijn, ongeveer hoeveel verzoeken dat kost, en of Beschikbaar op per store view daarna ook wordt gelezen.
• Er wordt niets verstuurd en niets anders overschreven. De gewone importregels gelden, en wijzigingen in Nexym die nog niet verstuurd zijn blijven staan.
• Vink Ik begrijp het aan; je hoeft de naam van de koppeling niet te typen.
• De voortgang en elk blok van 100 staan in Runs & logs. De koppeling krijgt tussendoor gewoon haar eigen syncs, en een limiet van de bron wordt afgewacht.

Een product waarvan de bron het veld echt leeg heeft, telt niet mee, en na het aanvullen komt de melding niet terug voor producten die de bron nog steeds niet invult. Kan een koppeling producten niet gericht op SKU lezen, dan staat de knop er niet: Nexym valt nooit terug op een volledige import.

Historie ophalen over een periode

In het venster van Historie ophalen… kies je twee datums:

• Van — de eerste dag die je wilt ophalen. Verplicht, en niet in de toekomst.
• Tot en met — de laatste dag, die helemaal meetelt. Standaard vandaag; laat je hem leeg of kies je een dag na vandaag, dan wordt het vandaag. Hij mag niet vóór Van liggen.

Bijvoorbeeld Van 1-1-2024 Tot en met 1-1-2026 haalt alles op wat in die twee jaar gewijzigd is, inclusief de hele dag 1 januari 2026, en niets daarbuiten. Alles ophalen vult Van met het begin van de tijd en Tot en met met vandaag: alles wat de bron heeft.

Nexym werkt van de einddatum terug naar de begindatum, in brokken van 30 dagen. Wat de hub al heeft, vraagt hij niet opnieuw op. Stopt het ophalen onderweg, dan gaat het verder waar het was. Op het tabblad staat tijdens het ophalen de periode met hoe ver het is (ophalen 1-1-2024 t/m 1-1-2026 · 40%), en dezelfde periode staat bij de laatste volledige sync, in Runs & logs (historie 1-1-2024 t/m 1-1-2026) en in het auditlog.

Een periode die eindigt vóór de datum bij Hub heeft gegevens vanaf vult alleen die periode. De datum in die kolom verandert dan niet, omdat er tussen jouw periode en die datum nog een gat zit.

Opgepast

Twijfel je of een export klopt? Kies eerst Basislijn opnieuw inlezen. Dat verstuurt niets; daarna gaat bij de volgende run alleen wat echt verschilt. Alles opnieuw versturen is voor als je zeker weet dat het doelsysteem alles opnieuw moet krijgen.

5Nu uitvoeren

Nu uitvoeren bij een regel laat eerst zien wat de run zou doen, en draait hem dan meteen. Het is altijd de volgende gewone run: bij een import wat sinds de vorige run bij de bron veranderde, bij een export wat veranderde. Aanmaken, Bijwerken en Ongewijzigd vergelijken elk record zoals de run het zou opslaan, dus na je mappings en regels. Het voorbeeld bekijkt hoogstens de eerste 200 records en zegt dat erbij; de run zelf verwerkt alles. Een regel die zijn eerste sync nog niet had, start je niet hier maar op Volledige sync.

Wat een export verstuurt

Een export (OUT) stuurt alleen wat het doelsysteem nog niet heeft:

• Alleen gewijzigde records. Een record dat sinds de vorige keer niet veranderde, gaat niet mee. Records die de hub net uit hetzelfde systeem heeft opgehaald, gaan er dus ook niet meteen weer heen: de hub onthoudt per record wat dat systeem heeft.
• Alleen gewijzigde velden. Van een record dat het systeem al heeft, gaan alleen de velden die anders zijn, plus de sleutel waarmee het systeem het record vindt (bij een product de SKU). Pas je bij drie producten de kleur aan, dan gaan er drie verzoeken met elk de SKU en de kleur.
• Een nieuw record gaat altijd compleet. Net als bij systemen die een record bij elke wijziging helemaal vervangen; dat staat per koppeling vast.
• Geen basislijn, dan niet versturen. Weet de hub van een gekoppeld record niet wat het doelsysteem heeft (een koppeling van vóór deze werkwijze), dan stuurt een gewone run het niet compleet: het record wordt tegengehouden, en de run zegt geen basislijn. Kies Basislijn opnieuw inlezen op het tabblad Volledige sync (of connect:baseline); daarna gaat alleen wat echt veranderde.

Nu uitvoeren telt records die het systeem al zo heeft als Ongewijzigd, en bij Veldmapping → Payload bekijken zie je precies wat er voor één record zou gaan.

Wil je toch het hele record sturen, bijvoorbeeld omdat iemand het in het doelsysteem heeft aangepast? Open het record en klik bij de koppeling op Opnieuw versturen. Dat stuurt het record compleet, ook als er niets veranderde.

Records die het doelsysteem niet meer heeft

Soms wijst de hub naar een record dat in het doelsysteem niet meer bestaat: het is daar verwijderd, of er is een oude back-up teruggezet. Standaard slaat de export zo’n record over. Dat is geen fout: in Runs & logs staat het als overgeslagen: niet aanwezig in met de naam van het systeem, en de hub probeert het pas weer als het record verandert.

Wil je dat de hub zo’n record opnieuw aanmaakt, zet dan bij de export-regel (het potlood bij de regel) Records die niet meer in … bestaan opnieuw aanmaken aan. Dat stel je per entiteit in: een product opnieuw aanmaken wil je soms wel, een order die de shop heeft verwijderd bijna nooit. De optie staat alleen bij entiteiten die het systeem kan aanmaken. Een record dat de hub nog nooit naar dat systeem stuurde, wordt altijd gewoon aangemaakt.

Een koppeling voor een deel van de stores

Heeft je project meer dan één store, dan kies je per koppeling voor welke stores hij is (bijvoorbeeld een ERP-administratie die alleen de verkopen van één store boekt). Zo’n koppeling krijgt bij een export alleen wat bij die stores hoort:

• Orders gaan op de website waarop ze geplaatst zijn. Weet de hub die niet, dan telt de koppeling waar de order binnenkwam, als die maar aan één store hangt.
• Facturen, zendingen en retouren volgen hun order; offertes en winkelwagens hun klant.
• Klanten horen bij de stores waar ze kochten, of bij de store van de koppeling waar ze binnenkwamen.
• Producten, voorraad, prijzen en andere stamgegevens gaan altijd mee: die zijn van alle stores samen. Wil je daar toch iets tegenhouden, gebruik dan een regel.

Wat bij een andere store hoort, is geen fout en staat ook niet in de wachtrij. In Runs & logs en bij het record staat het als Niet verstuurd: niet voor de stores van deze koppeling (of de store is niet bekend… als de hub niet kan zien bij welke store het hoort). De hub kijkt er pas weer naar als het record verandert. Een record dat het doelsysteem al had, blijft daar staan: het wordt nooit verwijderd omdat het bij een andere store hoort.

Voeg je later een store toe aan de koppeling, dan gaat er niets vanzelf. De oudere records die nu wél mogen, worden geteld op het tabblad Volledige sync; jij beslist of ze gaan.

Een koppeling voor alle stores, en elk project met één store, werkt precies als voorheen.

Je eigen wijzigingen blijven staan

Een import overschrijft nooit een veld dat je in Nexym wijzigde en dat nog niet verstuurd is. Gaat dezelfde entiteit ook terug naar dat systeem, dan wordt je wijziging binnen een minuut na het opslaan verstuurd. Wijzigde het systeem hetzelfde veld ook, dan staat dat onder Operaties → Mislukte records → Conflicten; wie dan wint stel je in bij de import-regel (het potlood), zie conflicten.

Wat je terugziet

• Operaties → Runs & logs: elke run, met aantallen en de tijd die hij kostte.
• Mislukken bij een import losse records, dan is de run niet groen. Hij staat op partial_error als er ook records binnenkwamen, en op error als alles mislukte. De melding noemt elke fout één keer, met hoe vaak hij voorkwam en een voorbeeldrecord. In de run zelf staat elk mislukt record met zijn eigen fout. De volgende run leest vanaf hetzelfde punt opnieuw, dus na je correctie komen de records alsnog binnen zonder volledige sync.
• Filtered in het log betekent dat een regel het record bewust overslaat — geen fout.
• Zegt een run N records skipped: not linked to this connection, dan kent deze koppeling die records nog niet. Ze zijn niet verstuurd; er is niets fout gegaan.
• Operaties → Runs & logs → Per record: elk record dat een run aanraakte, met wat er gebeurde.
• De widget Status koppelingen op het Dashboard en de badges onder Koppel → Koppelingen laten zien of een systeem traag is of faalt.
• Knijpt een systeem je af, dan zie je dat bovenaan elke tab van die koppeling en in Runs & logs. Het tempo stel je per koppeling in op het tabblad Instellingen, blok Rate limits.

Waarom staan er twee koppelingen voor één systeem?

Dat mag, en soms moet het: een testomgeving naast productie, of een tweede winkel met eigen inloggegevens. Elke koppeling heeft zijn eigen veldmapping en regels, dus wat je voor de een instelt raakt de ander niet.