WhatsApp API-key veilig beheren — lekken voorkomen en erop reageren

Je API-key is de enige sleutel die iemand nodig heeft om berichten te versturen namens jouw WhatsApp-nummer. Geen wachtwoord, geen tweede verificatie — wie de key heeft, kan de API aanroepen alsof hij jouw bedrijf is. Toch behandelen veel teams die key achteloos: hardcoded in een script, gedeeld via Slack, of jarenlang ongewijzigd gebruikt door iedereen die ooit toegang kreeg. Dit artikel loopt door wat je concreet anders kan doen.

Wat de key precies kan

Elke aanroep naar de TextMeFlow API — of dat nu de moderne /v1/* REST-API is of de TextMeBot-compatibele /send.php-route — identificeert zich met diezelfde key, als Authorization: Bearer <je_api_key> header of als ?apikey=-parameter. Er is geen aparte read-only variant: wie de key heeft, kan berichten versturen, volledig punt. Dat betekent dat een uitgelekte key niet alleen een privacyrisico is, maar ook een operationeel risico: iemand die de key misbruikt om massaal ongevraagde berichten te sturen, duwt je nummer recht in het vizier van het anti-spampijplijn — en in het slechtste geval naar een Meta-ban, met jouw klanten als collateral damage.

Waar de key wél en niet mag staan

De vuistregel is simpel: de key staat nooit in versiebeheer. Concreet:

• Zet hem in een .env-bestand of in de secrets-manager van je hostingplatform (Railway, Fly.io, een .env op de server die niet in git zit), nooit hardcoded in een .js-, .php- of .py-bestand dat je commit.
• Zet .env in je .gitignore vóór je het eerste bestand aanmaakt, niet achteraf — een key die ooit gecommit is, blijft in de git-historiek staan, ook na een latere verwijdering.
• Deel een key nooit via chat, e-mail of een gedeeld document. Gebruik de secrets-functie van je team-tool (GitHub Actions secrets, Vercel environment variables, 1Password) in plaats van copy-paste.
• Als je met een freelancer of agency werkt die tijdelijk toegang nodig heeft, geef die toegang via een omgeving die je achteraf kan intrekken (een gedeelde secrets-vault), niet door de key zelf door te sturen.

Voor wie net begint met de API: de volledige authenticatie-flow staat beschreven in /docs/api en de stappen om een eerste key aan te maken in /docs/getting-started.

Webhooks zijn een ander verhaal

Let op het onderscheid: je API-key stuurt berichten, maar binnenkomende webhooks (berichtstatussen, antwoorden van klanten) worden niet met die key beveiligd. Die zijn HMAC-signed — TextMeFlow ondertekent elke webhook-payload met een eigen secret, zodat jouw endpoint kan verifiëren dat het verzoek echt van TextMeFlow komt en niet van iemand die je webhook-URL heeft geraden. Dat is een apart secret met een andere rol dan je API-key, en het verdient een eigen zorgvuldige opslag. Hoe je die handtekening checkt, staat uitgewerkt in Webhook-signatures verifiëren.

Wanneer moet je roteren

Er zijn een paar momenten waarop je niet moet wachten tot er iets misgaat:

• Een medewerker of freelancer met toegang vertrekt. Als de key ooit gedeeld is met iemand die het bedrijf verlaat, is dat het moment om hem te vervangen — niet "ergens dit kwartaal".
• Je vindt de key per ongeluk in een gecommit bestand, een publieke repo of een logbestand. Ga er vanaf dat moment van uit dat hij gecompromitteerd is, ook als je niet zeker weet of iemand hem al gebruikt heeft.
• Je ziet berichten de deur uitgaan die jij niet geïnitieerd hebt. Dat is het duidelijkste signaal van misbruik en vraagt om onmiddellijke actie.

Vermoed je een lek, neem dan contact op met TextMeFlow-support zodat de bestaande key ongeldig gemaakt wordt en je een nieuwe krijgt. Werk daarna elke plek bij waar de oude key stond — scripts, automatiseringen, CI/CD-secrets — want een vergeten plek met de oude key betekent gewoon een stille storing in productie zodra die key niet meer werkt.

Eén key, meerdere integraties

De meeste teams gebruiken dezelfde key in meerdere tools: een n8n-flow, een backend-script, een Airtable-automation. Dat is op zich geen probleem, maar het maakt rotatie wel vervelender — je moet overal bijwerken. Houd daarom een lijst bij van waar de key gebruikt wordt (een regel in een intern wiki-document is genoeg) zodat een rotatie geen speurwerk wordt. Voor teams die op meerdere nummers werken, is een los toestel per team of vestiging vanaf het Business-plan beschikbaar, wat rotatie en toegangsbeheer per nummer eenvoudiger maakt dan alles door één gedeelde key te laten lopen.

Nog geen account? Maak een gratis TextMeFlow-account en begin met een key die je vanaf dag één correct opslaat — dat is makkelijker dan achteraf opruimen.