Zendesk API Token Dönemi Bitiyor: OAuth Geçişi Nasıl Planlanmalı?

30 Nisan 2027, Zendesk ekosisteminde daha güvenli ve modern bir dönemin kapılarını aralıyor. Zendesk, şirketler için mevcut entegrasyonlarını OAuth standartlarıyla yenileyerek sistem mimarilerini güçlendirmeleri adına stratejik bir fırsat sunuyor. Zendesk’in 28 Temmuz 2026’da başlattığı kademeli geçiş süreci, entegrasyon envanterinizi gözden geçirip erişim güvenliğini optimize etmeniz için size değerli bir zaman ve zemin sağlıyor. Bu geçiş dönemi, yalnızca teknik bir güncelleme değil, dijital altyapınızı daha sürdürülebilir, izlenebilir ve esnek bir yapıya kavuşturmak için atılacak stratejik bir adım olarak görülmeli.

Zendesk API token nedir ve neden kaldırılıyor?

Zendesk API token, bir entegrasyonun kullanıcı parolası paylaşmadan Zendesk API’lerine erişmesini sağlayan sabit bir kimlik bilgisidir. Uzun süre entegrasyon kurmanın pratik yollarından biri oldu. Ancak bu kolaylık, ölçek büyüdükçe görünür hâle gelen üç temel sınırlama taşıyor: Tokenların kendiliğinden sona ermemesi, belirli bir uygulamaya bağlı olmaması ve tokenı kullanan hesabın yetkileri üzerinden geniş erişim sağlayabilmesi.

Başka bir ifadeyle tokenın hangi sistemde saklandığı, kim tarafından kullanıldığı veya hâlâ gerekli olup olmadığı düzenli biçimde izlenmiyorsa kalıcı bir erişim anahtarı yıllarca açık kalabiliyor. OAuth ise erişimi bir istemci ve belirli bir yetkilendirme akışı etrafında kuruyor; kısa ömürlü access tokenlar ve gerektiğinde yenileme mekanizmalarıyla kimlik bilgilerinin yaşam döngüsünü yönetilebilir hâle getiriyor. Zendesk’in API token yerine OAuth’a geçiş kararı, bu güvenlik ve yönetişim farkına dayanıyor.

Zendesk API token takvimi: Hangi tarihte ne değişiyor?

Tarih	Değişiklik
28 Temmuz 2026	30 gün boyunca kullanılmayan Support API tokenları pasifleştirilmeye başladı. Yeni açılan Zendesk hesapları API token oluşturamıyor veya kullanamıyor.
27 Ekim 2026	Mevcut hesaplarda da yeni API token oluşturma dönemi sona erecek. Aktif tokenlar, daha önce pasifleşmedikleri sürece son tarihe kadar çalışabilecek.
30 Nisan 2027	Kalan tüm Support API tokenları kalıcı olarak devre dışı bırakılacak. Yeniden etkinleştirme imkânı ve Admin Center’daki token yönetim ekranları kaldırılacak.

 

Takvimin en kritik ayrıntısı, düşük frekanslı entegrasyonlarda ortaya çıkıyor. Ayda bir çalışan bir finans raporu, dönemsel veri aktarımı veya yalnızca belirli bir olayda devreye giren otomasyon 30 günlük eşiği aşabilir. Pasifleştirilen token 60 gün içinde yeniden etkinleştirilmezse kalıcı olarak silinir. Üstelik 27 Ekim’den sonra kaybedilen bir tokenın yerine yenisini oluşturmak da mümkün olmayacak. Zendesk’in resmî duyurusu, geçişin kademeli ilerlediğini açıkça ortaya koyuyor.

Hangi Zendesk entegrasyonları etkilenebilir?

Değişiklik, Support API tokenlarıyla kimlik doğrulayan Ticketing, Help Center ve Voice API bağlantılarını kapsıyor. Başlıca risk alanları şunlar:

• CRM, ERP ve müşteri veri platformu senkronizasyonları
• E-ticaret, sipariş, iade ve teslimat bilgisi aktaran bağlantılar
• CTI ve çağrı merkezi entegrasyonları
• Veri ambarı, iş zekâsı ve dönemsel raporlama görevleri
• Ticket oluşturan veya Zendesk verisini güncelleyen webhooklar
• Özel uygulamalar, zamanlanmış scriptler ve middleware akışları
• Dış geliştiriciler veya üçüncü taraf sağlayıcılar tarafından kurulmuş bağlantılar

Her Zendesk ürünü veya her entegrasyon otomatik olarak etkilenmiyor. Belirleyici soru, ilgili sistemin API çağrısını hangi kimlik doğrulama yöntemiyle yaptığı. Bu ayrımı yalnızca uygulama listesine bakarak görmek mümkün değil; token kullanımıyla gerçek iş akışının eşleştirilmesi gerekiyor.

Asıl risk, görünür entegrasyonlardan çok sahipsiz bağlantılarda

Kurumsal sistemlerde entegrasyon envanteri çoğu zaman güncel uygulama mimarisini değil, geçmişte alınmış kararların izlerini gösterir. Bir ajansın yıllar önce kurduğu webhook, işten ayrılan bir çalışanın hesabıyla çalışan raporlama scripti veya sadece kampanya dönemlerinde devreye giren veri aktarımı günlük operasyonda görünmez kalabilir.

Bu bağlantılardan biri durduğunda sonuç her zaman açık bir sistem kesintisi olarak ortaya çıkmaz. Ticketlar oluşmayabilir, müşteri ve sipariş verileri eşleşmeyebilir, raporlar eksik veriyle üretilmeye devam edebilir. Teknik hata ile iş etkisi arasındaki mesafe büyüdükçe sorunun fark edilmesi de gecikir. Bu yüzden OAuth geçişinin ilk sorusu “kaç tokenımız var?” değil, “hangi müşteri süreci hangi erişime bağımlı?” olmalı.

OAuth’a geçmek neden yalnızca tokenı değiştirmek değildir?

API isteğinin başlığındaki statik tokenı bir OAuth access token ile değiştirmek, dönüşümün görünen kısmıdır. Sağlam bir Zendesk OAuth mimarisi; istemci türünü, yetkilendirme akışını, token yaşam döngüsünü, erişimi kullanan hesabı, güvenli saklamayı ve hata senaryolarını birlikte ele alır.

Kullanıcının giriş yapıp erişime onay verdiği uygulamalarda authorization code akışı; kullanıcı etkileşimi olmadan çalışan veri hatları ve arka plan görevlerinde ise client credentials akışı gündeme gelir. Bu iki model aynı işletim mantığına sahip değildir. Authorization code akışında süresi dolan access tokenın refresh token ile yenilenmesi gerekir. Client credentials modelinde yeni access token, istemci bilgileriyle yeniden talep edilir.

Zendesk’in varsayılan yaşam süreleri access token için 30 dakika, refresh token için 30 gündür; izin verilen aralıklar yapılandırmaya göre değişebilir. Ayrıca mevcut local OAuth clientların süre sonu ve token yenileme gereksinimlerine uyumunun en geç 1 Nisan 2027’ye kadar tamamlanması gerekiyor. Dolayısıyla yalnızca API token kullanan bağlantılar değil, daha önce OAuth’a geçirilmiş entegrasyonlar da token yenileme akışı açısından gözden geçirilmeli.

Zendesk OAuth geçişi nasıl planlanmalı?

1.Token envanterini iş akışlarıyla eşleştirin

Admin Center’daki aktif ve pasif tokenları; açıklama, son kullanım tarihi, ilişkili kullanıcı ve erişilen API endpointleriyle birlikte çıkarın. Ardından her tokenı bir uygulama, sunucu, script, webhook veya tedarikçiyle eşleştirin. Sahibi ve kullanım amacı bulunamayan tokenlar, en yüksek inceleme önceliğine sahip olmalı.

2.İş etkisine göre önceliklendirin

Ticket oluşturma, müşteri veya sipariş verisi aktarma, çağrı süreçlerini yürütme gibi operasyonu doğrudan etkileyen bağlantıları ilk dalgaya alın. Düşük frekanslı görevleri “kritik değil” diye sona bırakmayın; 30 günlük pasifleşme kuralı nedeniyle en erken sorun çıkarabilecek grup tam olarak bunlar olabilir.

3.Her entegrasyon için doğru OAuth akışını seçin

Kullanıcı adına çalışan uygulamalarla server-to-server bağlantıları aynı OAuth tasarımına zorlanmamalı. İstemci türü, bağlantının ihtiyaç duyduğu kullanıcı ve yetki modeli, secret saklama yöntemi ve yeniden yetkilendirme senaryosu ayrı ayrı belirlenmeli. Tek bir OAuth clientı bütün entegrasyonlarda paylaşmak yerine erişimleri ve hata alanlarını birbirinden ayırmak, yönetimi kolaylaştırır.

4.Başarısızlık senaryolarını test edin

Başarılı bir API çağrısı geçiş testinin yalnızca başlangıcıdır. Access tokenın süresinin dolması, refresh tokenın geçersizleşmesi, yeni tokenın güvenli biçimde kaydedilememesi, 401 yanıtı, yetki eksikliği ve secret rotasyonu gibi durumlar test edilmeli. İzleme ve uyarı mekanizmaları da entegrasyonun sessizce durmasını engelleyecek biçimde kurulmalı.

5.Kontrollü geçiş ve kapatma yapın

Önce test ortamında, ardından önceliklendirilmiş dalgalarla canlıya geçin. OAuth bağlantısı doğrulandıktan sonra eski API token üzerinden trafik gelmediğini izleyin. Geri dönüş planı hazır tutulmalı; fakat nihai hedef tokenı açık bırakmak değil, bağımlılığı güvenli biçimde ortadan kaldırmak olmalı. Zendesk’in OAuth geçiş rehberi, uygulama seviyesindeki teknik adımları ayrıntılandırıyor.

30 Nisan’ı proje başlangıcı değil, bitiş çizgisi olarak görün

OAuth geçişinde takvim baskısından daha büyük sorun, kurum içindeki belirsizliktir. Entegrasyon sahipleri, dış sağlayıcıların hazırlık durumu, test kapasitesi ve canlıya geçiş pencereleri son aylara bırakıldığında aynı anda çözülmesi gereken bağımlılıklar hızla çoğalır. 27 Ekim 2026’dan sonra yeni API token oluşturulamaması da geri dönüş seçeneklerini daraltır.

Doğru hedef, Nisan 2027’ye yetişmek değil; kritik bağlantıları çok daha önce OAuth üzerinde kararlı, izlenebilir ve yenilenebilir hâle getirmektir. Böylece zorunlu bir güvenlik değişikliği, Zendesk entegrasyonlarının sahipliğini ve dayanıklılığını yeniden kurmak için kullanılabilir.

GrowOn ile Zendesk OAuth geçişinizi planlayın

GrowOn için OAuth geçişi geleceğe dönük bir hazırlık başlığı değil. Mevcut Zendesk müşterilerimizin API token yapılarını bugün analiz ediyor; riskli bağlantıları belirliyor ve OAuth geçişlerini uçtan uca yürütüyoruz. Token envanterinden doğru OAuth mimarisinin kurulmasına, güvenli kimlik bilgisi yönetiminden test ve kontrollü canlı geçişe kadar sürecin her adımında ekiplerin yanında yer alıyoruz.

Yıllara dayanan dijitalleşme ve danışmanlık deneyimimiz sayesinde geçişi yalnızca teknik gereksinimler üzerinden değil; iş sürekliliği, erişim güvenliği ve entegrasyon sahipliği açısından da ele alıyoruz. İster mevcut Zendesk ortamınızı dönüştürüyor ister Zendesk’i ilk kez değerlendiriyor olun, GrowOn’un Zendesk Premier Partner uzmanlığıyla güvenli, yönetilebilir ve gelecekteki ihtiyaçlarınıza hazır bir yapı kurabilirsiniz.

Zendesk’i doğru entegrasyon mimarisi ve GrowOn uzmanlığıyla keşfetmek için 14 günlük ücretsiz denemenizi başlatın. Mevcut API ve OAuth yapınızı değerlendirmek için GrowOn ekibiyle iletişime geçin.