QLS koppeling met je webshop, via de API of kant-en-klaar.

QLS is een Nederlandse fulfilment- en pakketdienst uit Dordrecht, gericht op webshops, naar eigen zeggen met ongeveer drieduizend shops als klant. Ze doen het hele traject van magazijn tot bezorging, en bezorgen pakketten in de Benelux ook zelf.

Dat laatste is het verschil met een partij die alleen magazijn is: opslag, picken, verpakken, labelen en bezorgen zitten bij dezelfde partij, dus er is één aanspreekpunt als er iets misgaat.

Heen gaan de orders, met adres, artikelen en de gekozen verzendwijze. Terug komen voorraad, verzendstatus en de track-and-tracecode, zodat je klantenservice in je eigen shop kan kijken en niet in een portaal van iemand anders.

Voor Shopify, WooCommerce, Magento 2, Shopware 6, Lightspeed en CCV Shop is er een kant-en-klare koppeling. In alle gevallen maak je aan de shopkant een API-sleutel aan die je in my.QLS zet. Draai je maatwerk, dan bouwen wij het op hun RESTful API.

QLS heeft twee API’s, en welke je gebruikt hangt af van de software waar je account op draait. Voor de huidige fulfilmentsoftware is dat de API op api.pakketdienstqls.nl, met Basic Auth en de inloggegevens van je QLS-account. Voor de pakketdienst en de nieuwe fulfilmentsoftware is er de my.QLS API op api.qls.nl, met een token dat je aanvraagt met een client id en een geheim, en met de versie in het adres, nu 2026-1.

In de huidige API zitten fulfilmentorders, producten met hun voorraad, inkooporders, retouren, zendingen, verzendmethoden, servicepunten en webhooks. Van een deel daarvan bestaan een versie 1 en een versie 2, en QLS raadt versie 2 aan omdat die sneller antwoordt. De nieuwe my.QLS API is kleiner en draait om orders, producten en retouren.

Vraag daarom bij de start na op welke software je account draait. Dat bepaalt welke documentatie geldt, en die vraag komt vóór de eerste regel code.

Heen gaat de order: adres, artikelen met hun aantallen, de verzendmethode, en een servicepunt als de klant het pakket daar wil ophalen. De API kent ook producten met barcodes, dus de koppeling houdt naast de orders je assortiment in QLS bij.

Terug komen de voorraad per product, de status van de order en de zending met de track-and-tracecode. Met webhooks meldt QLS een verandering, zoals een nieuwe status, meteen aan je shop, in plaats van dat je shop er steeds om moet vragen.

Verzend je zelf en gebruik je QLS als pakketdienst, dan gaat het vooral om labels. Bij het ophalen van bestellingen uit de webshop druk je de pakbonnen af, scan je ze één voor één en komt het verzendlabel uit de labelprinter. Zendingen en labels kunnen ook automatisch worden aangemaakt voor één of meer bestellingen.

Er zijn meer dan tien vervoerders aan te sluiten, van PostNL en DHL tot DPD en Trunkrs. Welke er per zending uit komt rollen bepaal je met regels: op gewicht, op bestemming, op wat de klant heeft gekozen, of op kosten.

Daar zitten de winst en het risico. De winst is dat je per zending de goedkoopste of de snelste kiest zonder dat iemand dat handmatig doet. Het risico is dat je site iets anders belooft dan de regel doet, en dan is het verschil niet zichtbaar tot een klant erover belt.

1. Toegang. Maak in my.QLS een apart account voor de koppeling, zodat een wachtwoordwijziging van een medewerker de orders niet stillegt. Voor de nieuwe API registreer je een client en krijg je een client id en een geheim.
2. Producten. Zet je assortiment in QLS, met barcodes, en controleer dat de artikelnummers in je shop en bij QLS gelijk zijn. Anders komt een order binnen op een artikel dat QLS niet kent.
3. Regels. Leg de vervoerderregels vast en leg ze naast wat je checkout belooft.
4. Test en livegang. Plaats een paar testorders, kijk of ze bij QLS binnenkomen en of status en tracking terugkomen in je shop, en annuleer ze daarna. Pas dan gaan de echte orders mee.

Je levertijd is een verkoopargument en staat in je advertenties, in je feed en in je checkout. Komt die uit drie verschillende plekken, dan lopen ze uit elkaar zodra er één verandert.

Met een sluitende integratie haal je de levertijd uit de plek waar hij werkelijk wordt bepaald. Dat scheelt afgekeurde feeds bij Merchant Center, en het scheelt de discussie achteraf of een klant nu terecht klaagde. Hoe de levertijd in je productfeed komt, staat bij de koppeling met Channable.

Bij de verwachting die je wekt. De koppeling werkt zoals afgesproken, maar de tekst in de checkout is een half jaar geleden getypt en niemand heeft hem sindsdien bekeken.

Het tweede is de voorraad bij meerdere kanalen. Verkoop je ook op bol, dan moet vastliggen welk kanaal welke voorraad mag verkopen. Zonder die afspraak verkoopt de marketplace het laatste artikel dat je eigen shop net verkocht.

Bij een deel van de onderdelen staat in de documentatie een limiet, zoals 60 aanroepen per minuut voor het ophalen van producten. Wie daaroverheen gaat, krijgt foutcode 429. Voor een shop die per order één aanroep doet is dat ruim, voor een koppeling die elke minuut de hele voorraad ophaalt niet. Daarom luisteren we naar webhooks voor wat verandert, en halen we de volledige voorraad alleen op vaste momenten op.

De andere bekende fout zit in de inloggegevens. Omdat de huidige API met Basic Auth werkt, stopt de koppeling zodra het wachtwoord van dat account verandert. Een apart account voor de koppeling, met het wachtwoord in een omgevingsvariabele, voorkomt dat. Wil je dit voor een maatwerkshop laten bouwen, zie dan design en development.