QR-code-API-gids: codes genereren en beheren (2026)

    QR Cake TeamGepubliceerd:

    Een gids voor ontwikkelaars over QR-code-API's: wanneer je ze inzet, de gangbare bewerkingen, voorbeelden in JavaScript en Python en hoe je een aanbieder kiest.

    QR-code-API-gids: codes genereren en beheren (2026)
    De meeste toepassingen van QR-codes (enkele tientallen codes voor menukaarten, visitekaartjes of marketing) worden prima bediend door de dashboardinterfaces van QR-generatorplatformen. Klik, plak een URL, download een afbeelding, klaar.

    QR API's komen echt tot hun recht wanneer je moet opschalen voorbij wat een persoon via een dashboard kan doen: per-klantcodes, per-bestelcodes, integratie met een ander systeem, bulkgeneratie gekoppeld aan een database. Goed ingezet laat een QR API je codes behandelen als infrastructuur: gegenereerd, beheerd en gevolgd door je eigen software.

    Deze gids behandelt wanneer QR API's de technische inspanning waard zijn, welke bewerkingen ze meestal ondersteunen, werkende codevoorbeelden en hoe je API's van verschillende aanbieders met elkaar vergelijkt.

    De korte versie van 30 seconden



    QR-code-API's zijn de moeite waard als:

    1. Je per-klant- of per-bestelcodes nodig hebt die programmatisch worden gegenereerd (evenementtickets, loyaliteitskaarten, anti-vervalsingsnummers).
    2. Je QR-generatie integreert in een groter systeem (je CRM, je voorraadbeheer, je e-commerceplatform).
    3. Je een volume genereert dat te omvangrijk is om handmatig via een dashboard te beheren: meestal meer dan enkele tientallen codes per maand.
    4. Je bestemmingen programmatisch moet bijwerken op basis van voorraad, tijd of gebruikersgedrag.


    Ze zijn overkill als:

    1. Je een handvol codes nodig hebt voor marketing. Het dashboard sneller en handiger is.
    2. De codes niet veranderen en het volume klein is. Statische generatie-tools volstaan dan.
    3. Je geen ingenieurscapaciteit hebt om een API-integratie te implementeren, onderhouden en monitoren.


    Veelvoorkomende QR API-bewerkingen



    De meeste QR API's bieden vijf of zes kernbewerkingen. De precieze endpointnamen verschillen per aanbieder, maar het patroon is vergelijkbaar.

    1. Genereer een nieuwe QR-code.

    POST een URL-bestemming (en optionele metadata) naar de aanbieder; ontvang een code-ID en een downloadbare QR-afbeeldings-URL.

    2. Bewerk de bestemming van een bestaande dynamische code.

    PUT of PATCH naar een code-endpoint om de redirect te wijzigen. Handig voor voorraadgestuurde bestemmingen, tijdsplanning of A/B-testen.

    3. Haal de analytics van een code op.

    GET scan-tellingen, tijdreeksen, geografische verdeling, apparaatverdeling van een code. Handig voor dashboard-integratie of rapportage.

    4. Toon of zoek bestaande codes.

    GET een paginaweergave van codes in je account, optioneel gefilterd op datum, tag of bestemming. Handig voor beheerinterfaces.

    5. Verwijder of archiveer een code.

    DELETE verwijdert de code volledig (codes stoppen met doorverwijzen). Sommige aanbieders bieden "archiveren" als een zachtere optie die pauzeert zonder te verwijderen.

    6. Bulkbewerkingen.

    Veel aanbieders bieden batch-eindpunten: maak meerdere codes tegelijk aan, werk alle codes bij die aan een filter voldoen, exporteer analytics voor veel codes. Deze hebben eigen limieten en prijsgevolgen.

    Authenticatiepatronen



    QR API's gebruiken meestal een van de drie authenticatiemodellen:

    API-sleutel in een header. Het eenvoudigste: voeg een Authorization Bearer-token header toe aan elk verzoek. Makkelijk te implementeren; het aandachtspunt is het beheer van sleutelrotatie en intrekking.

    OAuth 2.0. Complexer maar beter voor integraties met meerdere gebruikers of partners. Token-gebaseerd, scope-gereguleerd, tijdsbeperkt.

    Ondertekende verzoeken met HMAC. Wordt door sommige aanbieders gebruikt in situaties met hoge beveiliging. De client ondertekent elk verzoek met een geheim en een tijdstempel, waardoor replay-aanvallen worden voorkomen.

    Voor de meeste gebruikssituaties werk je met het API-sleutelmodel. Sla de sleutel op in omgevingsvariabelen op, commit deze nooit in versiebeheer en roteer regelmatig.

    Codevoorbeelden



    De voorbeelden hieronder gebruiken een generiek QR API-patroon. Vervang de basis-URL door het daadwerkelijke eindpunt van je aanbieder en pas veldnamen aan indien nodig.

    Genereer een code in JavaScript (Node.js):

    Een typische Node fetch-aanroep verstuurt een POST met JSON met de bestemmings-URL, label en type code. De reactie bevat een code_id en image_url die je kunt opslaan en gebruiken.

    Genereer een code in Python:

    Het equivalent in Python gebruikt de requests-bibliotheek om dezelfde JSON payload te POST'en. Gebruik omgevingsvariabelen voor de API-sleutel en gooi een fout bij niet-2xx-responses.

    Werk de bestemming van een code bij:

    Een PATCH-verzoek naar het eindpunt van de code met de nieuwe bestemmings-URL wijzigt waar elke bestaande, afgedrukte kopie nu naartoe verwijst.

    Ontvang scan-analytics:

    Een GET-verzoek naar het analytics-eindpunt van de code, optioneel met queryparameters voor datumbereik, retourneert tellingen en uitsplitsingen.

    Dit zijn illustratieve patronen. Raadpleeg altijd de specifieke documentatie van je aanbieder voor daadwerkelijke eindpunten en request/response-formats.

    Veelvoorkomende API-gebruikssituaties



    De patronen die vaak terugkomen in echte QR API-integraties:

    Codes per bestelling of per klant.

    E-commerce: elke bestelling verzendt een unieke QR code die linkt naar de specifieke landingspagina van die klant (herbestellen, reviewverzoek, bezorgtracking, enz.). De code wordt door de API gegenereerd bij het afrekenen, de afbeelding verwerkt in het verpakkingssjabloon.

    Codes per ticket of per deelnemer bij evenementen.

    Evenemententicketing: elk ticket krijgt een unieke QR code die bij de ingang wordt gevalideerd. Dezelfde API kan later codes voor terugbetaling/overdracht of follow-up na het evenement verstrekken.

    Traceerbaarheidscodes per product.

    Productie en FMCG: variabel-data printen plaatst een unieke code op elk product, gekoppeld aan de batch, herkomst en traceergegevens. Vereist door sommige regelgevingen zoals FSMA 204 en FDA UDI.

    Codes per locatie of per regio.

    Bedrijven met meerdere locaties: de API genereert een code per locatie, waarbij de bestemming wordt ingesteld op de pagina of het check-in proces van die locatie. Updates worden via de API doorgevoerd wanneer locaties openen, sluiten of details wijzigen.

    Bestemmingen op basis van voorraad.

    Detailhandel: QR-codes op schaplabels verwijzen naar de productpagina, maar de bestemming verandert wanneer het product in de aanbieding gaat, uitverkocht raakt of wordt vervangen door een nieuw variant. De API werkt bestemmingen bij op basis van voorraadgebeurtenissen.

    Loyaliteits- en beloningscodes.

    Horeca en detailhandel: iedere klantenkaart heeft een unieke QR-code. De code linkt naar het loyaliteitsprofiel van die klant. De API geeft codes uit bij registratie en werkt de routeringslogica in de loop van de tijd bij.

    Anti-namaak codes.

    Premium producten: elk exemplaar krijgt een unieke QR-code. De API houdt scanpatronen bij: meerdere scans vanaf verschillende locaties met dezelfde code (wat onmogelijk zou moeten zijn voor een unieke, authentieke code) signaleren mogelijke namaak.

    Snelheidslimieten en bulkbewerkingen



    QR-API's hanteren snelheidslimieten: grenzen aan het aantal verzoeken per seconde, minuut of uur dat je kunt maken.

    Typische snelheidslimieten:

    • Gratis / hobbyist niveaus: 60 verzoeken per minuut.
    • Middenklasse betaald: 1.000-10.000 verzoeken per minuut.
    • Enterprise: maatwerk (doorgaans 100.000+ verzoeken per minuut of onbeperkt met fair-use beleid).


    Voor bulkgeneratie heb je twee opties:

    1. Sequentiële generatie met snelheidslimietbeheer. Doe individuele API-aanroepen in een lus, waarbij je 429 (Too Many Requests) fouten opvangt en tijdelijk wacht. Eenvoudig, geschikt voor volumes tot een paar duizend.
    2. Bulk endpoints. Veel aanbieders bieden endpoints die arrays van codes in één verzoek accepteren. Veel efficiënter bij hoge volumes.


    Voor zeer hoge volumes (miljoenen codes) bieden sommige aanbieders asynchrone bulkgeneratie aan: je levert een opdracht in, vraagt periodiek de status op, en downloadt een CSV-bestand met resultaten. Altijd beschikbaar bij enterprise plannen; soms ook bij lagere niveaus.

    Webhooks versus polling



    QR-API's ondersteunen doorgaans twee manieren om scan-gebeurtenissen te ontvangen:

    Polling. Je applicatie belt periodiek de analytics endpoint aan om te controleren op nieuwe scans. Eenvoudig te implementeren, maar niet real-time en verspilt calls als er geen nieuwe activiteit is.

    Webhooks. De aanbieder stuurt een POST naar een URL op jouw server elke keer dat een scan plaatsvindt (of volgens een configureerbare planning). Real-time, efficiënt, maar vereist dat je server een publieke endpoint beschikbaar stelt en inkomende verzoeken valideert.

    Voor real-time toepassingen (event ticketing, fraudedetectie, directe klantbetrokkenheid triggers) zijn webhooks essentieel. Voor periodieke rapportages is polling voldoende.

    Vergelijking van QR-API's tussen aanbieders



    De meeste grote QR-aanbieders bieden APIs aan, maar de volwassenheid varieert sterk.

    Waar je op moet letten:

    • Kwaliteit van de documentatie. Een goed gedocumenteerde API met voorbeelden bespaart ontwikkeltijd. Test door de documentatie door te lezen en te proberen je voor te stellen hoe je het eenvoudigste geval zou implementeren.
    • Snelheidslimieten. Stem de limieten van de aanbieder af op je verwachte volume.
    • Prijsmodel. Per code, per verzoek, maandabonnement met gebruiksvergoeding, of een combinatie daarvan.
    • Webhook-ondersteuning. Essentieel voor realtime toepassingen.
    • Beschikbaarheid van bulk-endpoints. Bespaart enorm veel tijd bij integraties met hoog volume.
    • Beschikbaarheid van SDK. Officiële SDK's in jouw programmeertaal verkorten de integratietijd aanzienlijk.
    • Beleid voor de levensduur van codes. Zelfde als bij dashboardgebruik: wat gebeurt er met je codes als je stopt met betalen?


    Opmerkingen van providers (ten tijde van schrijven):

    • Uniqode en qr-code-generator.com (Bitly Inc.) beschikken over volwassen, enterprise-grade API's met een breed scala aan functies. De hogere prijs weerspiegelt dit.
    • QR Tiger heeft een degelijke API tegen een toegankelijkere prijs.
    • QR Cake biedt API-toegang bij betaalde abonnementen; documentatie en SDK-beschikbaarheid worden verbeterd.
    • Bitly's QR API is echt krachtig als je al geïntegreerd bent met Bitly voor korte links.


    Vergelijk de huidige documentatie en prijzen voordat je een keuze maakt. API's veranderen. Het Best QR Code Generators artikel behandelt het bredere landschap van providers.

    Beveiligingsoverwegingen



    QR code API's kennen een paar specifieke beveiligingsvalkuilen die het vermelden waard zijn:

    1. Opslag van API-sleutels.

    Zorg dat je sleutels nooit in versiebeheer zet. Gebruik omgevingsvariabelen, secret managers (AWS Secrets Manager, HashiCorp Vault, Doppler) of de ingebouwde secrets van je platform. Draai sleutels om wanneer medewerkers vertrekken of wanneer sleutels per ongeluk zijn blootgesteld.

    2. Validatie van bestemming-URL.

    Als gebruikers van je applicatie de bestemming-URL van QR codes kunnen opgeven (bijvoorbeeld in een multi-tenant app waar klanten hun eigen codes aanmaken), valideer dan altijd de URL's. Voorkom open-redirect aanvallen door geen willekeurige bestemmingen toe te staan.

    3. Verificatie van webhook-handtekening.

    Als je webhooks gebruikt, ondertekent de provider payloads meestal met een geheim. Controleer de handtekening van elke binnenkomende webhook: zonder deze controle kan een aanvaller scan-evenementen namaken.

    4. Rate limiting aan jouw kant.

    Als je QR-codegeneratie openstelt aan eindgebruikers (bijvoorbeeld een klantgerichte app), implementeer dan zelf rate limiting. Anders kan één slechte actor je quotum bij de provider uitputten.

    5. Controle van codebestemming.

    Voor langlevende codes (op verpakking, visitekaartjes) registreer elke bestemmingswijziging. Als een aanvaller je provideraccount compromitteert en bestemmingen wijzigt naar phishing-URL's, is het auditlogboek je forensisch bewijs.

    Veelvoorkomende fouten bij QR API's



    Fout 1: QR-generatie als een eenmalige setup beschouwen. Codes vereisen beheer: updates, archivering, monitoring. Bouw voor voortdurende werking, niet alleen voor de initiële creatie.

    Fout 2: Niet testen van de snelheidslimieten (rate limits). Het bereiken van de snelheidslimiet van je provider tijdens een Black Friday-campagne is een slecht moment om dit te ontdekken.

    Fout 3: De QR-afbeelding opslaan in plaats van de code-ID. Sla altijd de code-ID van de provider op (zodat je de code later kunt bijwerken of verwijderen). De afbeelding is slechts een cached weergave.

    Fout 4: Geen retry-logica implementeren. API's kunnen af en toe falen. Zonder retries met exponentiële backoff veranderen tijdelijke fouten in permanente bedrijfsproblemen.

    Fout 5: Webhook handtekeningverificatie negeren. Een webhook-endpoint zonder handtekeningverificatie is een publiek toegankelijke URL die iedereen kan vervalsen.

    Fout 6: Het domein van de provider hard-coderen in je codes. Gebruik een aangepast domein (je subdomein dat wijst naar de infrastructuur van de provider) zodat je later van provider kunt wisselen zonder gedrukte codes te wijzigen.

    Fout 7: Codes genereren die naar staging-URL's verwijzen. Codes die op verpakking worden gedrukt of naar klanten worden verzonden en naar staging-URL's verwijzen vormen een reëel risico. Valideer de bestemmingen.

    Fout 8: Vergeten bestemmingen bij te werken wanneer URL's veranderen. Als je URL-structuur verandert bij een site redesign, moet de bestemming van elke dynamische code worden bijgewerkt. Dit is gemakkelijk te missen.

    Veelgestelde vragen



    Heb ik een API nodig om dynamische QR-codes te gebruiken? Nee. De meeste providers van dynamische QR-codes hebben dashboards die de meeste gebruikssituaties afhandelen zonder API-integratie. API's zijn bedoeld voor programmatische generatie op schaal.

    Kan ik QR-codes genereren zonder de API van een provider? Ja, voor statische codes. Bibliotheken zoals qrcode (Python, JavaScript) en pyqrcode genereren lokale statische QR-afbeeldingen zonder externe dienst. Voor dynamische codes (met bewerkbare bestemmingen en analytics), heb je een provider nodig.

    Is het gratis om een QR code API te gebruiken? Sommige providers bieden gratis tiers aan met beperkte aantallen verzoeken. De meeste betaalde plannen bevatten API-toegang. Vergelijk prijzen per verzoek en per code.

    Kan ik meerdere QR API-providers in één applicatie gebruiken? Ja, technisch gezien. Elke code is gekoppeld aan de provider die deze heeft gegenereerd. Het mixen van providers maakt het beheer complexer; meestal is het beter te standaardiseren op één provider.

    Hoe migreer ik van de ene QR API-provider naar een andere? Je genereert nieuwe codes bij de nieuwe provider. Oude codes blijven verwijzen naar de servers van de oude provider totdat ze worden verwijderd (of stoppen met doorverwijzen als het oude abonnement eindigt). Als je een aangepast domein gebruikte, kun je de DNS wijzigen naar de infrastructuur van de nieuwe provider zonder codes opnieuw te genereren; dit is de migratievriendelijke route.

    Kan ik miljoenen QR-codes genereren via API? Ja, met enterprise-abonnementen die passende snelheidslimieten en bulk-endpoints bieden. Controleer of dit wordt ondersteund door jouw gekozen plan voordat je eraan begint.

    Ondersteunen QR API's webhooks? De meeste enterprise- en veel midtier-plannen wel. Gratis en instapplannen meestal niet. Controleer dit voordat je op webhooks vertrouwt voor productieomgevingen.

    Hoe lang duurt het om een QR API te integreren? Eenvoudig gebruiksscenario (een code genereren in je bestaande app): enkele uren. Productieklare integratie met foutafhandeling, herhalingspogingen, monitoring en webhookverwerking: enkele dagen. Volledige enterprise-integratie met bulkbewerkingen, aangepaste domeinen en SSO: weken.

    Werken mijn QR-codes nog als de API uitvalt? Genereren en bewerken werkt dan niet meer. Reeds gegenereerde codes blijven functioneren zolang de redirect-infrastructuur van de provider actief is; die is meestal gescheiden van de API-infrastructuur en heeft hogere betrouwbaarheidseisen.

    Kan ik een QR-codeservice volledig op mijn eigen infrastructuur draaien? Voor statische codes: ja. Er bestaan bibliotheken in alle grote programmeertalen. Voor dynamische codes met redirects en analyse kun je het zelf bouwen, maar dan beheer je eigenlijk een kleine SaaS. Voor de meeste teams is het goedkoper om een provider te gebruiken dan zelf te bouwen.

    Conclusie



    QR APIs zijn infrastructuur voor bedrijven die verder schalen dan wat een mens kan beheren via een dashboard. De patronen zijn goed bekend: genereren, bijwerken, analytics ophalen, archiveren. Kies een provider waarvan de API-volwassenheid past bij jouw behoeften, integreer zorgvuldig en behandel codes op de lange termijn als een beheerde bron.

    Lees meer over de prijzen en API-toegang van QR Cake

    Klaar om je eigen QR-code te maken?

    Maak een dynamische QR-code die je na het printen nog kunt aanpassen. Start gratis, zonder creditcard, met onbeperkte scans, en je codes verlopen nooit.

    QR Cake Team

    Over het QR Cake-team

    Geschreven door het QR Cake-team: de mensen achter QR Cake, een platform voor dynamische QR-codes dat wordt gebruikt voor aanpasbare printcampagnes, Canva QR-codes, scananalyses en duurzame QR-redirects die blijven werken nadat abonnementen aflopen.

    Meer weten over QR Cake

    Veelgestelde vragen

    Heb ik een API nodig om dynamische QR-codes te gebruiken?
    Nee. De meeste dynamische QR-providers hebben dashboards die de meeste gebruikssituaties dekken zonder API-integratie. API’s zijn bedoeld voor programmatische generatie op schaal.
    Kan ik QR-codes genereren zonder de API van een provider?
    Ja, voor statische codes. Bibliotheken zoals qrcode (Python, JavaScript) genereren statische QR-afbeeldingen lokaal. Voor dynamische codes met aanpasbare bestemmingen en analytics heb je een provider nodig.
    Hoe migreer ik van de ene QR API-provider naar een andere?
    Genereer nieuwe codes bij de nieuwe provider. Oude codes blijven verwijzen naar de servers van de oude provider totdat ze worden verwijderd. Als je een aangepast domein gebruikte, wijzig je de DNS naar de nieuwe provider zonder de codes opnieuw te genereren.
    Werken mijn QR-codes nog als de API van de provider uitvalt?
    Genereren en bewerken werkt dan niet meer. Reeds gegenereerde codes blijven functioneren zolang de redirect-infrastructuur actief is, meestal gescheiden van de API en met hogere betrouwbaarheidseisen.
    Kan ik miljoenen QR-codes genereren via een API?
    Ja, met enterprise-abonnementen die de juiste limieten en bulk-endpoints bieden. Controleer vooraf of dit wordt ondersteund in het gekozen plan.
    Hoe lang duurt het om een QR API te integreren?
    Eenvoudig gebruiksscenario: enkele uren. Productieklare integratie met foutafhandeling, herhalingspogingen, monitoring en webhooks: enkele dagen. Volledige enterprise-integratie met bulkbewerkingen en SSO: weken.