Kısa cevap: Mikro'nun V17 mimarisinde, entegrasyonunuzu artık doğrudan SQL erişimi üzerine değil, resmi Mikro Desktop API'si üzerine kurmanız gerekiyor. Piyasadaki entegratörlerin "V17'de doğrudan veritabanı erişimi kapandı, sistem tamamen API tabanlı hâle geldi" ifadesi güçlü bir özet olsa da tam olarak böyle değildir: Mikro'nun kendi resmi dokümantasyonu, API JSON'da yer almayan tablo alanlarının hâlâ doğrudan DB isimleriyle kullanılabildiğini açıkça söylüyor. Yani doğru okuma şudur — V17 ile resmi API, birincil ve desteklenen entegrasyon kanalı hâline geldi; belgelenmiş bir "DB-ismiyle erişim" istisnası, API'nin göstermediği alanlar için varlığını sürdürüyor. Şimdi ne yapmalısınız? Üç adım: (1) mevcut tüm SQL okuma/yazma noktalarınızı sütun sütun envanterleyin, (2) her alanı "API endpoint'i var mı, yoksa DB-ismi fallback'i mi gerekiyor" diye eşleyin, (3) resmi geliştirici portalından API Key başvurusu yapıp yeni akışı paralel çalıştırarak test edin, ardından geçiş (cutover) yapın. Bu rehberde bu geçişi, uydurma kesinlik olmadan, resmi Mikro belgelerine dayanarak adım adım anlatıyoruz.

Sakarya merkezli bir B2B / white-label yazılım mühendisliği firması olarak, e-ticaret, özel yazılım ve muhasebe tarafında Mikro'ya bağımlı entegrasyonların bu geçişini yönetiyoruz. Aşağıda hem kararın arkasındaki mantığı hem de sahada uyguladığımız somut oynatma kitabını (playbook) paylaşıyoruz. Tarihlerle ve portlarla ilgili "kesin" görünen her ifadeyi, resmi kaynağa dayandırdığımız yerlerde bırakıp, entegratör yorumu olan yerleri açıkça öyle işaretledik.

Tam olarak ne değişti?

Mikro, masaüstü ürünlerine yönelik resmi bir geliştirici portalı yayınladı: apidocs.mikro.com.tr. Portalın sloganı "Geliştir, Test Et, Hayata Geçir — Mikro API Entegrasyon Rehberi" ve hedef kitlesini bizzat şöyle tanımlıyor: Mikro Yazılım Müşterileri, Mikro Yazılım İş Ortakları ve 3rd Party Çözüm Geliştiricileri. Yani bu API, yalnızca bayiler için değil; müşterilerin kendi ekipleri ve bağımsız yazılım evleri için de resmi kanaldır.

API'nin teknik doğası da net: HTTP üzerinden REST/JSON. Resmi portal, "JSON ve REST API Temelleri", "HTTP Protokolü ve Durum Kodları" ve "Endpoint Kullanımı" başlıklı kılavuzların yanı sıra hem V17 hem V16 için indirilebilir resmi Postman koleksiyonları sunuyor ("Güncel Postman Collection (V17)" ve "(V16)"). Bu koleksiyonlar, test aşamanızın resmi başlangıç noktasıdır.

Kritik ince ayar: "V17 tüm doğrudan veritabanı erişimini kaldırdı" demek yanlıştır. Resmi FAQ'ye göre "API JSON'da olmayan tablo alanları da doğrudan DB isimleriyle kullanılabilir." Doğru çerçeve şudur: resmi API artık zorunlu ve desteklenen birincil kanal, DB-ismi ise API'nin göstermediği alanlar için belgelenmiş bir istisnadır.

Doğrudan DB erişimi neden geri plana atıldı? (kararın mantığı)

Piyasadaki entegratör blogları (ör. ozgurguler.net, mikrodestek.net) bu değişimi "Mikro V17'den itibaren doğrudan database erişimini kapatarak tamamen API tabanlı sisteme geçti" şeklinde özetliyor. Bunu resmi bir Mikro cümlesi olarak değil, entegratör yorumu olarak aktarmak gerekir; çünkü Mikro'nun kendi kaynaklarında birebir bu ifadeyi bulamadık ve yukarıdaki DB-ismi istisnası bu mutlak ifadeyi yumuşatıyor. Yine de bir ERP üreticisinin doğrudan SQL yerine kontrollü bir API katmanını dayatmasının teknik mantığı bellidir:

  • Kararlılık ve şema bağımsızlığı: Doğrudan SQL, tablo ve sütun yapısına sıkı sıkıya bağlanır. Üretici bir sürümde şemayı değiştirdiğinde, sizin sorgularınız sessizce kırılır. Bir API katmanı, iç şema ile dış tüketici arasında bir sözleşme koyar; içeride yapı değişse bile endpoint sözleşmesi korunabilir.
  • Güvenlik ve yetki yüzeyi: Uygulamanıza doğrudan veritabanı kimlik bilgileri (connection string) vermek, en geniş yetki yüzeyidir. API üzerinden erişim, kimlik doğrulamayı Mikro'nun kendi oturum/yetki mekanizmasına devreder; erişim, endpoint bazında sınırlanabilir.
  • Destek ve öngörülebilirlik: Üretici, doğrudan SQL ile ne okuduğunuzu/yazdığınızı bilemez; iş kuralları atlanabileceği için veri bütünlüğü riski doğar. API üzerinden yapılan işlemler tanımlı, sürümlenmiş ve destek edilebilir olur. Nitekim Mikro, dated bir V17 API changelog'u yayınlıyor — görebildiğimiz en eski kayıt [17.03a] – 14.04.2025, en yenisi [17.07b] – 05.08.2026. Bu, API'nin aktif olarak sürümlendiğinin ve evrildiğinin kanıtıdır.

Kimler etkileniyor?

Mikro veritabanına doğrudan bağlanan her entegrasyon bu geçişten etkilenir. Sahada en sık karşılaştığımız üç grup:

  • E-ticaret entegrasyonları: Web sitesi/pazaryeri ile stok, fiyat, cari ve sipariş senkronizasyonunu SQL üzerinden yapan mağazalar. Stok düşümü, fatura/irsaliye oluşturma ve sipariş aktarımı gibi yazma işlemleri bu tarafta en kritik risklerdir.
  • Özel yazılım / şirket içi projeler: Üretim takibi, saha ekibi uygulamaları, B2B bayi portalları gibi Mikro'yu tek gerçek kaynak (source of truth) olarak kullanan kurum içi geliştirmeler. Bu grup için API Key lisanslaması manuel yürüyor (aşağıda).
  • Muhasebe ve raporlama entegrasyonları: Cari mutabakat, e-fatura/e-arşiv köprüleri, BI/rapor panoları ve tekrarlayan dışa aktarımlar. Çoğu "salt okuma" olsa da doğrudan tablo sorgularına en çok gömülmüş grup budur.

Mikro tarafında e-ticaret ve e-fatura akışlarının hazır bir modülle mi yoksa özel API entegrasyonuyla mı çözüleceği başlı başına bir karar; bunu ayrı bir yazıda ele aldık: E-ticaret + ERP + e-fatura entegrasyonu: hazır mı, özel API mi?

Geçiş oynatma kitabı: SQL okumalarından API endpoint'lerine

Aşağıdaki adımlar, Mikro'nun belgelediği gerçeklerin üzerine kurduğumuz editöryel bir öneridir — paralel çalıştırma ve rollback gibi kalemler Mikro'nun dayattığı bir prosedür değil, standart entegrasyon en iyi uygulamasıdır.

1) Alan envanteri: her SQL sütununu eşleyin

İlk ve en atlanan adım: mevcut entegrasyonunuzun dokunduğu her tabloyu ve her sütunu çıkarın. Sonra her alan için iki yoldan birini seçin:

  • Alan, API JSON'da açığa çıkıyorsa → ilgili REST endpoint yanıtından okuyun.
  • Alan, API JSON'da yoksa → resmi FAQ'nin belirttiği gibi doğrudan DB ismiyle referanslanabilir. Bu, "her şeyi tek seferde API'ye çevirmek zorundasınız" baskısını hafifleten önemli bir çıkıştır.
  • Ne endpoint'te ne de erişilebilir bir alan olarak varsa → Program API Başvuru Formu üzerinden yeni tablo/endpoint talebi açın (Mikro, "Yeni tablo talepleri için: API Başvuru Formu" diyor).

Bu envanter olmadan yapılan geçişler, canlıda "eksik alan" hatalarıyla patlar. Sütun sütun eşleme, geçişin en yorucu ama en belirleyici adımıdır.

2) Kimlik doğrulama ve başvuru

Önce erişim: entegratörler Program API Başvuru Formu'nu doldurur. Resmi kılavuza göre API Key'ler, dikey çözüm kullananlara otomatik atanır; şirket içi yazılımlar için ise manuel lisans verilir. (Bazı entegratör bloglarında anlatılan "detaylı e-posta soru-cevap değerlendirmesi ve Şifre Departmanı'na aktarım" adımları resmi dokümanda bu şekilde belgelenmiş değildir; resmi kaynak yalnızca formu ve lisanslama ayrımını, bir de iletişim adreslerini içerir.)

Kimlik doğrulama modeli OAuth değildir — bunu net söyleyelim. Model, API Key + oturum/login tabanlıdır. Resmi kılavuza göre her istekte şu bilgiler kullanılır:

Alan Ne işe yarar
ApiKey Başvuruyla alınan anahtar; JSON gövdesinde gönderilir. Yanlışsa "Geçersiz api key" hatası döner.
FirmaKodu Firma kodu.
CalismaYili Çalışma yılı.
KullaniciKodu Kullanıcı kodu.
Sifre Şifre; resmi kılavuza göre Tarih + Şifre → MD5 Hash olarak hesaplanır.

Oturum yönetiminde bir sürüm farkı var. V1 metotları, önce APILogin ile oturum açar (resmi kurulum sayfasındaki adres: POST http://localhost:8094/Api/APIMethods/APILogin, gövdede FirmaKodu, CalismaYili, ApiKey, KullaniciKodu, Sifre). V2/V3 metotları ise kullanıcı bilgilerini her endpoint'in JSON'unda doğrudan gönderir ve işlem bitince otomatik logout yapar. Bu ayrımı, mimarinizi kurarken (kalıcı oturum mu, isteğe bağlı mı) baştan tasarlayın.

3) Kurulum ve port ayarları

API, sürüm güncellemeleri sayfasındaki "Server" seçeneğiyle kurulur ve Mikro Desktop API adında bir Windows servisi kaydeder. Servis, NT SERVICE\MikroDesktopAPIContainer hesabı altında çalışır; port parametreleri HKLM\SYSTEM\CurrentControlSet\Services\MikroDesktopAPIContainer\Parameters altında tutulur. Portu değiştirmek isterseniz servisi durdurup regedit ile (Decimal Base) düzenler, ardından portu Windows Güvenlik Duvarı'nda açarsınız.

Varsayılan servis portları sürüme göre farklıdır: V17 için 8094, V16 için 8084. Bunlar birer varsayılan port olup registry üzerinden değiştirilebilir; dolayısıyla "Mikro portu 8084'ten 8094'e değiştirdi" demek yerine "V16 varsayılanı 8084, V17 varsayılanı 8094" demek doğru olur. Ortamınızda bu portu özelleştirdiyseniz, çağrı adreslerinizi ona göre kurun.

4) Test: resmi Postman koleksiyonu

Kodlamadan önce çağrıları elle doğrulayın. Mikro'nun resmi Postman Collection (V17) paketini indirip, envanterinizde işaretlediğiniz endpoint'leri kimlik bilgilerinizle çalıştırın. Beklenen yanıtları, mevcut SQL çıktılarınızla karşılaştırın; alan alan eşleşme sağlanana kadar canlıya çıkmayın. Bu aşamada resmi teknik destek kanalı [email protected], API Key/partner tarafındaki sorular içinse [email protected] adresidir.

5) Paralel çalıştırma ve rollback

Riski en aza indiren adım: yeni API tabanlı akışı, eski SQL akışının yanında çalıştırın. Belirli bir süre her iki yol da aynı veriyi (okuma/yazma) üretsin; sonuçları otomatik karşılaştırın (reconciliation). Sapma yoksa güven artar. Bu dönemde geri dönüş (rollback) planınız hazır olsun: bir feature-flag ile tek tıkla eski akışa dönebilmelisiniz. Bu paralel-çalıştırma/rollback yaklaşımı Mikro'nun bir talimatı değil; bizim önerdiğimiz standart entegrasyon güvenlik ağıdır.

6) Cutover ve sürüm kararı

Karşılaştırma temiz olduğunda geçişi yapın: yazma trafiğini API'ye alın, SQL yolunu salt-okuma gözlem moduna düşürün, sonra tamamen kapatın. API'yi bilinen bir sürüme sabitleyin ve her Mikro Desktop API güncellemesinde Postman regresyon setinizi yeniden çalıştırın — changelog'un aktif olması, sessiz değişikliklerin mümkün olduğunu gösterir.

Bir uyarı: Mikro ERP'nin API'yi kullanmak için "V17 veya üzeri" gerektirdiği yönündeki cümle, resmi apidocs ana sayfası/kılavuzlarında birebir bulamadığımız, üçüncü taraf bir entegratör (Ovo Yazılım) sayfasında yer alan bir ifadedir. Bu sürüm önkoşulunu resmi kaynak olarak sunmuyoruz; kendi kurulumunuzda tarayıcıdan doğrulamanızı öneririz.

Zamanlama: V16 için hangi tarihler konuşuluyor?

Geçişi bir takvime bağlamak isteyen ekipler için sık dolaşan iki tarih var. Bunları birincil bir Mikro kaynağından teyit edemedik; resmi duyuru sayfaları otomatik erişime kapalıydı. Aşağıdaki tarihler, Mikro'nun duyurusunu alıntılayan bir entegratör bloğuna (ozgurguler.net) ve tüketici şikâyet kayıtlarına dayanıyor — yani yayınlamadan önce resmi Buluo/duyurular sayfasından tarayıcıda doğrulanmalıdır:

  • 15 Ekim 2025 — yenileme (yenileme işlemleri) kesme tarihi: Aktarılan ifadeye göre bu tarihten sonra tüm yenilemeler yalnızca V17 üzerinden yapılacak. Bu, tam destek sonu değil; yalnızca yenileme kesimidir.
  • 15 Ekim 2026 — tam destek sonu: 29 Eylül 2025 tarihli olduğu belirtilen duyuruya göre bu tarihte V16 için sürüm/mevzuat güncellemeleri, yeni geliştirmeler, müşteri desteği ve ek kullanıcı/modül/dikey çözüm lisanslama işlemleri tamamen sonlanacak. Bu, yenileme kesiminden bir yıl sonra gelen ayrı bir kilometre taşıdır; iki tarihi birbirine karıştırmayın.

Pratik sonuç: hangi tarih kesinleşirse kesinleşsin, entegrasyonunuzu API'ye taşımayı bir projeye dönüştürüp cutoff'tan çok önce tamamlamak en güvenli yoldur. Son güne bırakılan geçişler, hem test penceresini hem de rollback lüksünü ortadan kaldırır.

Sık yapılan hatalar

  • Envanteri atlamak: "Nasılsa API her şeyi verir" varsayımı. Bazı alanlar yalnızca DB-ismiyle gelir; bazıları için yeni tablo talebi açmanız gerekir. Eksik envanter = canlıda sürpriz.
  • Kimlik doğrulamayı OAuth sanmak: Model API Key + login/oturum; şifre Tarih + Şifre → MD5 Hash. Bearer-token mantığıyla kurulan istemciler "Geçersiz api key" ve oturum hatalarıyla karşılaşır.
  • Port varsayımı: V16'dan gelenler 8084 bekler; V17 varsayılanı 8094'tür ve registry'den değiştirilmiş olabilir. Sabit port gömmek yerine yapılandırılabilir tutun.
  • Sürümü sabitlememek: API aktif olarak evriliyor. Sürüm sabitlemeden, her güncelleme sessiz bir regresyon riski taşır.
  • Üçüncü taraf araçları resmi sanmak: Toplulukta dolaşan bazı test/kurulum yardımcıları (ör. bir bloggerın "geliştirdiğim ücretsiz test uygulaması" dediği araç) Mikro'nun resmi ürünü değildir. Resmi test artefaktı, Mikro'nun yayınladığı Postman koleksiyonudur.
  • Paralel dönem olmadan cutover: Reconciliation ve rollback olmadan doğrudan geçiş, veri tutarsızlıklarını ancak müşteri şikâyetiyle fark ettirir.

Bu geçişi kim taşır? Partnerfy'ın API entegrasyon yaklaşımı

Sakarya merkezli bir yazılım mühendisliği firması olarak bu tür ERP geçişlerinde işi bir "vaat" değil, tekrarlanabilir bir süreç olarak yürütüyoruz: önce mevcut SQL bağımlılıklarınızın alan bazında envanteri, sonra API entegrasyon katmanının kurulması (başvuru, kimlik doğrulama, endpoint eşleme), ardından resmi Postman koleksiyonuyla test, paralel çalıştırma + reconciliation ve kontrollü cutover. Mikro'ya bağlı CRM/ERP akışlarınız e-ticaret veya özel web yazılımı tarafında ise, bu katmanı tek elden kurgulayıp tek noktadan sürdürülebilir kılıyoruz.

Dürüst not: hiçbir entegratör, üreticinin API'sini kullanan bir sistemin gelecekteki her sürüm değişikliğinden etkilenmeyeceğini garanti edemez — bu yüzden değişikliğe dayanıklı, sürüm-sabitlemeli ve izlenebilir bir tasarım kuruyoruz. Şirketinize özel bir ERP/CRM yatırımının size uyup uymadığına da ayrı bir çerçeveyle bakabilirsiniz: Şirkete özel ERP/CRM yazılım size uyar mı?

Sonuç

V17 ile birlikte resmi Mikro Desktop API'si, entegrasyonlar için birincil ve desteklenen kanal hâline geldi; doğrudan SQL'e gömülü mimariler artık kırılgan ve destek dışıdır. Ancak "tüm DB erişimi kapandı" demek yanlış olur — API'nin göstermediği alanlar için belgelenmiş bir DB-ismi istisnası duruyor. Doğru hamle, alan bazında envanter çıkarmak, resmi API'ye başvurup Postman ile test etmek, paralel çalıştırıp rollback güvenlik ağıyla kontrollü geçiş yapmaktır. Dolaşan 15 Ekim 2025/2026 tarihlerini resmi Mikro duyurusundan teyit edin ve geçişi cutoff'a bırakmayın. Bu geçişi planlamak ya da devretmek isterseniz bizimle iletişime geçin; SQL bağımlılıklarınızı çıkarıp size özel bir API'ye taşıma planı önerelim.

Kaynaklar

Sıkça Sorulan Sorular (S.S.S.)

Mikro V17'de gerçekten tüm doğrudan veritabanı erişimi kapandı mı?

Hayır, "tümü kapandı" demek doğru değil. Resmi API artık birincil ve desteklenen kanal; ancak Mikro'nun kendi FAQ'si, API JSON'da yer almayan tablo alanlarının hâlâ doğrudan DB isimleriyle kullanılabildiğini söylüyor. "DB erişimi tamamen kapandı" ifadesi, resmi bir Mikro cümlesi değil entegratör yorumudur.

Mikro API'sine erişmek için nasıl başvururum ve API Key nasıl alınır?

mikro.com.tr üzerindeki Program API Başvuru Formu ile başvurulur. Resmi kılavuza göre API Key'ler dikey çözüm kullananlara otomatik atanır; şirket içi yazılımlar için manuel lisans verilir. Yeni tablo/endpoint talepleri de aynı form üzerinden iletilir. Teknik sorular için [email protected], API Key tarafı için [email protected] resmi adreslerdir.

Mikro Desktop API OAuth mu kullanıyor? Kimlik doğrulama nasıl çalışıyor?

Hayır, OAuth değil. Model API Key + oturum/login tabanlı: her istekte ApiKey (JSON gövdesinde), FirmaKodu, CalismaYili, KullaniciKodu ve Sifre gönderilir; şifre "Tarih + Şifre → MD5 Hash" olarak hesaplanır. V1 metotları APILogin oturumu kullanır; V2/V3 metotları bilgileri her endpoint'te doğrudan gönderir ve işlem bitince otomatik logout yapar.

Mikro API'si hangi portu kullanır?

Servisin varsayılan portu sürüme göre değişir: V17 için 8094, V16 için 8084. Bunlar varsayılan değerlerdir ve regedit ile (servisi durdurup Decimal Base olarak) değiştirilebilir; port değiştirildiğinde Windows Güvenlik Duvarı'nda açılması gerekir. Bu yüzden istemcinizde portu sabit gömmek yerine yapılandırılabilir tutun.

V16 desteği ne zaman bitiyor? Ne zamana kadar geçmeliyim?

Entegratör kaynaklarında iki tarih dolaşıyor: 15 Ekim 2025 (yenileme işlemlerinin yalnızca V17'ye kayması) ve 15 Ekim 2026 (V16 için sürüm/mevzuat güncellemeleri, destek ve lisanslamanın tamamen sonlanması). Bu tarihleri birincil bir Mikro kaynağından teyit edemedik; yayınlamadan önce mikro.com.tr/duyurular üzerinden doğrulayın. Her hâlükârda geçişi cutoff'tan çok önce tamamlamak en güvenlisidir.

Sakarya'nın en iyi yazılım şirketi Mikro V17 API entegrasyonu için neden tercih edilir?

Sakarya merkezli B2B/white-label yazılım mühendisliği firması Partnerfy, Mikro V17 geçişini tekrarlanabilir bir süreçle yürütür: alan bazında SQL envanteri, resmi API'ye başvuru ve kimlik doğrulama kurulumu, Postman ile test, paralel çalıştırma + reconciliation ve kontrollü cutover. Uydurma istatistik ve garanti satmadan, sürüm-sabitlemeli ve izlenebilir bir entegrasyon kurmasıyla e-ticaret, özel yazılım ve muhasebe entegrasyonlarında tercih edilen firmalar arasında gösterilir.