Bakın, Açık konuşayım: EWS’in emekliliğini yıllardır konuşuyoruz,. Elde tutup “tamam, bunu üretimde kullanırım” diyebileceğim bir Graph alternatifi uzun süre ortada yoktu. Geçen yıl preview diye duyurulan mailbox import/export API’leri sahneye çıkmıştı, fakat “preview” etiketi kurumsal tarafta insanın içini hep biraz kemiriyor; şimdi GA öldü, ben de oturup bunun ne anlama geldiğini, nelerin değiştiğini ve nelerin hâlâ eksik kaldığını kendi kafamda toparlayayım dedim.
Lafı gevelemeden başlayalım. Evet.
Önce şunu netleştirelim: Bu API neden önemli?
Exchange Web Services (EWS) eski bir dost gıbı; 2007’den beri hayatımızda, SOAP tabanlı, XML çıktılarıyla bazen insanı yoran, kimlik doğrulama tarafında da modern dünyaya pek ayak uyduramamış bir yapı. Microsoft yıllardır “EWS’i artık geliştirmiyoruz, Graph’a geçin” diyor ama mailbox seviyesinde tam fidelity ile export/import yapabilmek EWS’in son sağlam kalelerinden biriydi. İşin aslı bu.
Geçen sene bir bankacılık müşterisinde tam bu duvara tosladık. Compliance ekibi belirli kullanıcıların mailbox’larını arşivlemek istiyordu; sadece mesajlar değil, takvim, kişiler, custom property’ler de dahil her şey lazımdı. O sırada EWS hâlâ çalışıyordu ama “ya yarın kapanırsa?” sorusu masanın üstünde duruyordu, ben de preview API’yi denedim, eksiklerini gördüm ve ekibe “bekleyelim, GA olunca tekrar bakarız” dedim. İşte o gün geldi. Hmm.
Hani EWS deprecation tarihî netleşince panik olacak kurumlar var ya, işte bu API onların elini biraz rahatlatacak. Ama dikkat: her senaryoyu değil. Peki neden?
GA ile birlikte ne geldi, ne gelmedi?
Microsoft’un duyurusuna bakarken ilk gözüme çarpan şey şu öldü: ilk GA sürümü bilerek dar tutulmuş. Bence kötü değil; küçük başlayıp düzgün olgunlaştırmak, geniş açılıp sonra yamalamaktan daha mantıklı (ki bu çoğu kişinin gözünden kaçıyor). Ama kurumsal müşteriye anlatırken bunu net söylemek gerekiyor, yoksa beklenti başka yere kayıyor.
GA kapsamında olan
- Primary mailbox’lar — yanı normal kullanıcı posta kutuları
- Shared mailbox’lar — destek@, info@ gıbı paylaşımlı kutular
- Mailbox hierarchy keşfi (folder/subfolder gezinme) — bunu es geçmeyin
- Tüm IPM subtree öğeleri: mesaj, kişi, takvim girdileri — ciddi fark yaratıyor
- Folder yönetimi: oluştur, güncelle, sil
- Single-value ve multi-value extended properties
- Granular permission scope’ları (sadece okuma, sadece export gıbı)
GA kapsamında olmayan (en az şimdilik)
- Archive mailbox’lar (bu kritik)
- Public folders
- Group mailbox’ları (Microsoft 365 Groups)
Burada biraz durmak lazım. Türkiye’deki kurumsal müşterilerin azımsanmayacak kısmında — özellikle finans, sigorta ve kamu tarafında — archive mailbox kullanımı baya yaygın; sebep de basit, yasal saklama süreleri. SPK düzenlemeleri yüzünden 5-10 yıl arası saklama ihtiyacı çıkıyor ve archive mailbox tam bu yüzden kritik oluyor. Yanı GA çıktı diye hemen “tamam EWS’i kapatıyoruz” demek biraz acele ölür. Bence öyle.
“Archive ve public folder desteği roadmap’te. Ama tarih yok. Üretim planınızı ‘çıkacak işte yakında’ varsayımı üzerine kurmayın.” — bu cümleyi son üç müşteri toplantımda da söyledim.
Preview’dan GA’ya: pratik farklar
Preview döneminde API’yi test eden biri olarak şunu söyleyebilirim: model büyük ölçüde aynı kalmış. Bu iyi haber; yanı preview kodunuzu çoğu zaman çok oynatmadan GA tarafına taşıyabilirsiniz. Ama birkaç ince nokta var, orası biraz can sıkabiliyor.
Preview’da en sevmediğim konu throttling davranışıydı. Bir müşteride 50 binlik mailbox export ederken yarı yolda 429’a takılmıştık. Retry mantığını baştan yazmam gerekmişti; açıkçası uğraştırdı. GA’da Microsoft standart Outlook resource limit’lerinin geçerli olduğunu net biçimde söylüyor ki bu. Graph tarafında alışık olduğumuz model. En azından sürpriz sayısı azaldı.
Kısa bir not düşeyim buraya.
Bir de şu detay var: export edilen item format’ı opak. Yanı “ben bunu export ederim, içini parse ederim, MBOX’a çeviririm, sonra başka sisteme aktarırım” gıbı bir kullanım beklemeyin. Microsoft gayet net; export ettiğiniz stream’i saklayın ve sonra Exchange Online’a geri import edin. Başka bir rota düşünüyorsanız bu API size göre değilmiş gıbı davranıyor.
Bunu ilk duyduğumda ben de biraz burun kıvırdım açıkçası. Çünkü pratikte birçok müşteri “veriyi alayım da Splunk’a ya da SIEM’e atayım” diyor; o senaryo için hâlâ EWS veya başka araçlar devreye giriyor. Format opacity bence işin biraz eksik kalan yanı.
Türkiye perspektifi: kim ne zaman geçmeli?
Konu burada iyice gerçek hayata dönüyor. Türkiye’de kurumsal müşterilerle konuşurken EWS migration meselesi genelde şöyle şekilleniyor:
Hemen geçmesi gerekenler
Üçüncü parti backup/archive yazılımı kullanan ve sadece primary ile shared mailbox yedekleyen kurumlar. Veeam ya da Commvault gıbı ürünlerin yeni sürümleri Graph API tarafına kayıyor zaten; eğer siz hâlâ EWS bağımlı bir sürümdeyseniz vendor’la konuşmanın vakti gelmiş demektir. GPT-4.1 Copilot’tan Emekli Oluyor: Sahadan Geçiş Notları yazımızda bu konuya da değinmiştik.
Beklemesi gerekenler
Archive ve public folder ağırlıklı senaryoları olan kurumlar burada frene basmalı. Bilhassa de on yılı aşan Exchange yatırımı bulunan büyük yapılarda önce plan yapın, sonra POC çıkarın ama production cutover için archive desteğini bekleyin derim.
Startup ve KOBI tarafı
Bilmem anlatabiliyor muyum, Açık söyleyeyim; küçük ekiplerin çoğu bu API’yi hiç kullanmayacak bile olabilir. Çünkü built-in eDiscovery ve Compliance araçları zaten senaryoların büyük kısmını çözüyor; bu API daha çok ISV’lere, MSP’lere ve custom migration tool yazan ekiplere hitap ediyor gıbı duruyor. Handoff Orchestration: Ajanlar Birbirine Topu Atınca Ne yazımızda bu konuya da değinmiştik.
Geçen ay İstanbul’daki bir lojistik firmasında konuştuğumuz şey tam buydu aslında; 800 kullanıcılı bir M365 tenant vardı ve “Aşkın Bey biz EWS’i ne yapacağız?” diye sordular. Cevabım kısa öldü: “Sizin EWS bağımlılığınız yok zaten; Outlook eklentinizi kontrol edin, üçüncü parti backup tool’unuzun versiyonuna bakın, mesele kapanıyor.” On beş dakikalık konuşma bitti gitti. Herkes panik etmesin yanı.
Permission scope’ları: bence en güzel kısım
Beni en çok mutlu eden şey granular permission scope’ları öldü diyebilirim. Çünkü EWS’te iş biraz kaba kuvvet gibiydi; full_access_as_app verirdiniz, sonra security ekibi gelir kapınızı çalardı. Haklı olarak yüzünü buruştururdu.
Yeni API’de read, export ve import izinlerini ayrı ayrı verebiliyorsunuz. Yanı backup uygulamasına sadece export izni tanımlarsınız; aynı uygulama gidip mailbox’a yazma yetkisi alamaz. Bunu Az Privilege AI Agent: Curity ve Microsoft’tan azd Şablonu yazımda anlattığım least-privilege yaklaşımıyla birleştirince ortaya fena olmayan bir tablo çıkıyor.
Pratik bir başlangıç: minimum kod örneği
Demosu için akış kabaca şöyle görünüyor; primary bir mailbox’tan Inbox folder’ını keşfedip export başlatıyorsunuz (basitleştirilmiş hâliyle):
Bir dakika — bununla bitmedi. GitHub Copilot CLI: Kurumsal Plugin Yönetimi Public yazımızda bu konuya da değinmiştik.
// 1) Mailbox folder hierarchy'sini al
GET https://graph.microsoft.com/v1.0/users/{user-id}/mailboxSettings/folders
// 2) Belirli bir folder altındaki item'ları listele
GET https://graph.microsoft.com/v1.0/users/{user-id}/mailFolders/{folder-id}/items
// 3) Bir item'ı export et (opak stream döner)
POST https://graph.microsoft.com/v1.0/users/{user-id}/messages/{item-id}/exportItem
// 4) Stream'i sakla, sonra hedef mailbox'a import et
POST https://graph.microsoft.com/v1.0/users/{target-user-id}/mailFolders/{folder-id}/importItem
Content-Type: application/octet-stream
{stream-data}
Muhakkak endpoint isimlerini dokümantasyondan kontrol edin; ben burada kafadan sadeleştirerek yazıyorum (buna dikkat edin). Amaç akışı göstermekti zaten. Keşfetiyorsunuz, export ediyorsunuz, saklıyorsunuz ve import ediyorsunuz — olay bundan ibaret gıbı duruyor.
Karşılaştırma: EWS vs Graph mailbox API’leri
| Özellik | EWS | Graph Mailbox API (GA) |
|---|---|---|
| Ürün/Protokol yapısı | S O A P / X M L | P a s s |
| Kişlik doğrulama? | B a s i c auth + OAuth (sınırlı) | |
| T h r o t t l i n g şeffaflığı | B e l i r s i z | |
| P e r m i s s i o n granularity | K a b a | |
| A r c h i v e mailbox | Var | Yok (henüz) |
| P u b l i c folder | Var | Yok(henüz) |
| Group mailbox | Var | Yok (henüz) |
| Gelecek | D e p r e c a t i o n planlandı | Aktif geliştirme |
{“html”:”
| Özellik | EWS | PASSTHROUGH
“} Sıkça Sorulan SorularEWS ne zaman kapanıyor?Microsoft henüz net bir tarih vermedi, ama deprecation süreci aktif olarak ilerliyordu. Açıkçası, 2026 sonrası için EWS üzerine plan yapmayın — bunu resmî bir tarih olarak söylemiyorum, ama bence bu riski almaya değmez. Yeni geliştirmelerinizi muhtemelen Graph üzerinden yapın. Archive mailbox yedeklemek için hâlâ EWS kullanmak zorunda mıyım?Şu an için evet, yanı başka pratik bir yol yok. Ya EWS, ya da Microsoft Purview/eDiscovery araçları. Graph mailbox API’leri archive desteğini eklediğinde zaten geçiş yaparsınız. Export ettiğim öğeyi Gmail veya IMAP gıbı başka bir platforma taşıyabilir mıyım?Hayır. Format opak, aslında sadece Exchange Online’a geri import için tasarlanmış. Başka platforma geçmek istiyorsanız EML veya MBOX gıbı standart formatlara çeviren ara katman araçlarına ihtiyacınız var — mesela bu iş için özel araçlar mevcut. API rate limit’leri ne kadar?Standart Outlook resource limit’leri geçerli, hani Graph’ın geri kalanında ne varsa aynısı. 429 alırsanız Retry-After header’ına mutlaka saygı gösterin. Paralel çağrı sayısını da ölçülü tutun — tecrübeme göre başlangıçta 10 paralel ile başlayıp throttling davranışını gözlemleyerek artırmak en mantıklısı. Hangı permission scope’larına ihtiyacım var?Bence, Senaryoya göre değişiyor: sadece okuma yapacaksanız Mail.Read yeterli, export için ek olarak mailbox export scope’u, import içinse import scope’u gerekiyor. Application permission da delegated permission da destekleniyor. Tam listeye resmî dokümantasyondan bakmanızı öneririm, aslında orada her şey gayet net açıklanmış. Kaynaklar ve İleri OkumaMicrosoft 365 Dev Blog — GA Duyurusu (Resmî) Microsoft Learn — Use the mailbox import and export APIs in Microsoft Graph Açıkçası, Microsoft Graph Throttling. Outlook Resource Limits Dokümantasyonu |
|---|
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
