Zendesk faseert API-tokens uit, stap over op OAuth

De deadlines op een rij en een helder stappenplan naar OAuth 

Wat verandert er aan de Zendesk API-tokens

Zendesk stopt gefaseerd met API-tokens als authenticatiemethode voor de Support-API. De uitfasering verloopt in drie stappen, elk met een eigen datum:

• 28 juli 2026: ongebruikte tokens worden automatisch gedeactiveerd.
• 27 oktober 2026: je kunt geen nieuwe API-tokens meer aanmaken.
• 30 april 2027: alle bestaande tokens worden permanent uitgeschakeld.

Die laatste datum is de harde grens. Werkt een koppeling na 30 april 2027 nog op een API-token, dan krijgt hij simpelweg geen toegang meer tot je Zendesk. Denk aan een integratie die tickets aanmaakt, klantdata synchroniseert of rapportages uit je omgeving trekt: op het moment dat het token wegvalt, stopt die uitwisseling.

Het advies van Zendesk is helder: migreer je integraties naar OAuth. Hoe eerder je begint, hoe meer ruimte je hebt om rustig te testen in plaats van te repareren onder tijdsdruk.

Waarom Zendesk API-tokens plaatsmaken voor OAuth

Een API-token werkt als een wachtwoord dat bij het hele account hoort. Iedere geverifieerde gebruiker, of iemand die het token in handen krijgt, kan er API-verzoeken mee doen. Het token is niet gekoppeld aan één persoon en het verloopt niet vanzelf. Handig in het gebruik, maar kwetsbaar zodra het uitlekt.

OAuth pakt dat anders aan. Een OAuth-token is gekoppeld aan een gebruikersaccount en erft precies de rechten van die gebruiker, niet meer. Via scopes beperk je een token tot alleen de toegang die de integratie echt nodig heeft. En OAuth-tokens zijn kortlevend: ze verlopen automatisch en vernieuwen zichzelf via een refresh-token. Lekt er een token, dan is de schade beperkt en tijdelijk.

Voor jou als beheerder betekent die overstap vooral meer grip. Je weet welke koppeling wat mag, je kunt toegang gericht intrekken en je loopt minder risico dat een oud, vergeten token ergens blijft rondslingeren. Dat sluit aan bij de bredere beveiligingseisen waar veel organisaties toch al mee te maken hebben. Wil je die basis breder tegen het licht houden, dan brengt een Zendesk Security Audit in kaart waar je omgeving nog risico's draagt.

Welke koppelingen raakt dit?

De belangrijkste vraag is: welke van jouw integraties gebruiken eigenlijk een API-token? Dat is niet altijd meteen zichtbaar, want een koppeling die netjes zijn werk doet, vraagt zelden aandacht. Loop in elk geval deze categorieën na:

• Maatwerkkoppelingen en scripts die je zelf of een leverancier heeft gebouwd
• Data-integraties die tickets of klantdata naar een datawarehouse of dashboard sturen
• Externe apps en tools die via de API met Zendesk praten
• Automatiseringen en middleware, bijvoorbeeld via platforms zoals Make of Zapier
• Interne systemen die tickets aanmaken of bijwerken vanuit een ander proces

Een overzicht van je actieve Zendesk-integraties is het startpunt. Weet je niet zeker welke koppelingen op tokens draaien of wie ze ooit heeft ingericht? Dan helpt een Zendesk Health Check om je omgeving door te lichten en de koppelingen boven water te krijgen die anders pas opvallen als ze stilvallen.

Zo migreer je op tijd naar OAuth

De migratie zelf volgt steeds hetzelfde patroon. Zendesk ondersteunt twee OAuth-varianten, en welke je kiest hangt af van wat de koppeling doet:

1. Inventariseer je koppelingen. Breng in kaart welke integraties een API-token gebruiken en wie de eigenaar is. Zonder dat overzicht mis je precies de koppeling die je over het hoofd ziet.
2. Kies de juiste OAuth-flow. Handelt de integratie namens een specifieke gebruiker die inlogt en toestemming geeft? Dan gebruik je de authorization code-flow. Draait het om een achtergrondproces of een server-naar-serverkoppeling zonder gebruiker, zoals een datapijplijn? Dan is de client credentials-flow de juiste keuze.
3. Maak een OAuth-client aan. Dat doe je in het Admin Center. De client vormt de basis waarmee je vervolgens tokens genereert.
4. Pas de integratie aan. Laat de koppeling niet langer een API-token meesturen, maar een OAuth-token via de Authorization-header. Bij de authorization code-flow zorg je bovendien dat de integratie tokens automatisch vernieuwt zodra ze verlopen.
5. Test in een veilige omgeving. Controleer of alles werkt voordat je live gaat, inclusief het gedrag rond verlopen tokens.

Voor een enkele standaardkoppeling is dat overzichtelijk werk. Heb je een landschap met veel maatwerk en meerdere integraties, dan wordt het al snel een project op zich, met testrondes en afstemming per koppeling. Een doordachte Zendesk implementatie en gestructureerd functioneel beheer helpen om die migratie beheerst uit te voeren, zonder dat je klantcontact eronder lijdt.

Waarom je hier nu al mee aan de slag wilt

Een deadline in april 2027 voelt ver weg. Toch is dit precies het soort project dat je beter niet tot het laatste kwartaal bewaart. De reden is simpel: je weet vaak niet welke koppelingen er allemaal draaien totdat je gaat zoeken, en elke migratie vraagt om testen. Begin je op tijd, dan doe je dat rustig en gecontroleerd. Begin je laat, dan repareer je onder druk, met het risico dat een integratie net in een drukke periode uitvalt.

De uitfasering van de Zendesk API-tokens is bovendien geen losse ergernis, maar onderdeel van een bredere beweging naar veiligere authenticatie. Wie nu migreert, ruimt meteen op: oude tokens eruit, gerichte toegang erin, en beter zicht op wie wat mag in je omgeving. Dat levert je meer op dan alleen het halen van een deadline.

Zie het dus niet als een verplicht klusje, maar als een moment om je koppelingen op orde te brengen. Met een helder overzicht en een plan per integratie is de overstap goed te overzien, en heb je er daarna jaren geen omkijken meer naar.

Wil je zeker weten dat al je koppelingen op tijd over zijn op OAuth? Plan een vrijblijvend gesprek met een van onze Zendesk-specialisten.