Sürüm Notları 2026
Sürüm 2026.09.0
ÖNEMLİ — SQL/JDBC trafik-log connector kullanıyorsanız aksiyon gerekli: Apinizer kurulumunuz API proxy trafik loglarını SQL/JDBC trafik-log connector'ı üzerinden ilişkisel bir veritabanına (Oracle, MySQL, PostgreSQL veya SQL Server) yazıyorsa, 2026.09.0 sürümüne yükseltmeden önce veya sırasında log tablosu güncelleme scriptini çalıştırmanız gerekir. Bu script, yeni AI Gateway, MCP Gateway, A2A Gateway ve yönlendirme teşhis bilgilerini ilgili log tablosuna ekler. Elasticsearch veya MongoDB trafik-log connector kullanıyorsanız bu adıma gerek yoktur — bu connector'lar yeni bilgileri zaten otomatik olarak taşır. Log Tablosu Güncelleme Scriptleri
ÖNEMLİ — API Portal API Product spec dosyaları: Bu sürümde API Product OpenAPI/spec yönetimi değişti. Yükseltmeden önce mevcut ürünlerinizin spec dosyalarını yedekleyin:
- Spec dosyası doğrudan yüklenerek oluşturulmuş ürünler: Spec’i yükseltmeden önce indirin. Yükseltme sonrasında her ürüne girip spec’i yeniden yüklemeniz gerekir.
- Apinizer üzerinden (proxy / katalog seçimiyle) oluşturulmuş ürünler: Spec’i yükseltmeden önce veya sonra indirebilirsiniz; yükseltme sonrasında yine her ürüne ayrı ayrı girip spec’i yeniden yüklemeniz gerekir.
Bu sürümün ana teması Apinizer AI Gateway modülüdür — LLM tabanlı servisleri, normal API'lerle aynı yaşam döngüsü, yönlendirme, güvenlik ve gözlemlenebilirlik modeli altına getiriyor.
-
AI Gateway — LLM Servislerini Diğer API'ler Gibi Yönetin
Mevcut API proxy modelinin yanına tam bir AI Gateway modülü eklendi: LLM servislerini tek bir OpenAI-uyumlu uç noktanın arkasına alan "AI" tipinde bir API proxy oluşturulabiliyor; bu proxy OpenAI, Azure OpenAI, Gemini, Bedrock, Vertex, DeepSeek, Moonshot ve Ollama (ve OpenAI-uyumlu kendi kurulumunuzdaki motorlar) için sağlayıcılarla destekleniyor, uçtan uca istek/yanıt akışlı (streaming) yanıtlarla birlikte. Bkz. APNZ-5128
-
Çoklu-Sağlayıcı Yönlendirme ve Otomatik Failover
AI proxy'ler maliyet veya gecikmeye göre sağlayıcılar arasında yönlendirme yapabiliyor, eşit öncelikli birden fazla birincil bağlantı arasında trafiği dağıtabiliyor ve bir birincil bağlantı hata verdiğinde veya erişilemez olduğunda yapılandırılmış bir yedek zinciri üzerinden otomatik olarak yedeklemeye geçebiliyor. Bkz. APNZ-5128
-
AI Guardrail Politikaları — Prompt, PII, DLP, Topic ve Loop Koruması
İstek ve yanıt trafiğini koruyan bir AI-özel guardrail politika ailesi eklendi: Prompt Guard jailbreak ve prompt enjeksiyon girişimlerini tespit ediyor (anlık, arka planda veya gölge modda değerlendirilebiliyor), PII Mask hem normal hem de akışlı yanıtlarda TCKN, IBAN ve telefon numarası gibi kişisel verileri maskeliyor, DLP Guard yapılandırılabilir gizli/hassas veri kalıplarına karşı eşleşmeleri blokluyor/işaretliyor/maskeliyor, Topic Guard konuşmaları onaylı bir konuda tutuyor, Context Integrity konuşma manipülasyonuna karşı koruyor, Loop Guard ise kontrolden çıkan tool çağrı döngülerini sınırlıyor. Guardrail preset'leri proje bazında bir kez tanımlanıp AI proxy'ler arasında yeniden kullanılabiliyor. Bkz. APNZ-5128
-
LLM Yanıtları için Semantic Cache
AI proxy'ler LLM yanıtlarını iki katmanda önbelleğe alabiliyor — birebir eşleşen prompt'lar için tam eşleşme önbelleği ve neredeyse aynı prompt'lar için anlam benzerliğine dayalı semantic cache — bu sayede sık sorulan sorular için istek sağlayıcıya ulaşmadan önce tekrarlanan maliyet ve gecikme azaltılıyor. Bkz. APNZ-5128
-
Token ve Maliyet Bütçeleri ile Rate Limiting
Token ve USD bütçeleri proje, uygulama, credential ve organizasyon kapsamında zorlanabiliyor; istek öncesi tahmini maliyete karşı rezervasyon ve yanıt tamamlandığında gerçek kullanıma karşı mutabakat uygulanıyor. Esnek üst sınırlar trafiğe izin vermeye devam ederken uyarı veriyor; katı üst sınırlar ise bir kota tükendiğinde sonraki istekleri reddediyor. Bkz. APNZ-5128
-
RAG (Retrieval-Augmented Generation) ve Knowledge Base'ler
Knowledge base'ler kendi dokümanlarınızdan (PDF yükleme, parçalara ayırma ve yinelenenleri ayıklama ile) oluşturulup seçtiğiniz bir vektör deposuna — pgvector, Qdrant veya Redis — Ollama veya OpenAI gibi bir sağlayıcı üzerinden kaydedilebiliyor. Bir RAG injection politikası istek anında ilgili pasajları getirip modelin yanıtını bu verilere dayandırıyor; bir knowledge base, dokümanları değiştikçe talep üzerine yeniden hazırlanabiliyor. Bkz. APNZ-5128
-
MCP Gateway — Inbound ve Outbound Model Context Protocol
Apinizer artık MCP'nin (Model Context Protocol) her iki tarafında da yer alıyor: inbound bir MCP sunucusu, herhangi bir AI proxy'yi MCP-uyumlu agent'ların keşfedip çağırabileceği bir tool seti olarak dışa açıyor; outbound bir MCP Tool Call politikası ise bir AI akışının bir isteği işlerken harici bir MCP sunucusundaki tool'ları çağırmasını sağlıyor. Bkz. APNZ-5128
-
A2A Gateway — Inbound ve Outbound Agent2Agent Protocol
Apinizer AI Gateway ayrıca A2A'yı (Agent2Agent) çift yönlü destekliyor: inbound tarafta bir AI proxy, agent kartı ve mesaj/görev yaşam döngüsüyle bir A2A agent olarak yayınlanabiliyor; outbound tarafta bir A2A Agent Call politikası bir AI akışının harici bir A2A agent'a iş devretmesini sağlıyor. Bkz. APNZ-5128
-
LLM Sağlayıcıları, Model Kataloğu ve Credential Bazlı Erişim
LLM sağlayıcı bağlantıları API anahtarlarını şifreli secret olarak saklıyor ve herhangi sayıda AI proxy'de yeniden kullanılabiliyor; bir model kataloğu maliyet takibi ve yönlendirme kararları için her modelin fiyatlandırma ve kabiliyetlerini tutuyor; tüketici tarafı erişim ise credential'lar üzerinden kapsamlanıyor — böylece belirli bir uygulama veya kullanıcıya, başkasınınkine dokunmadan kendi model ve bütçe erişimi verilebiliyor. Bkz. APNZ-5128
-
AI Analitik ve Gözlemlenebilirlik
Elasticsearch tabanlı bir AI analytics katmanı her AI isteğini sağlayıcı, model, token sayıları, maliyet, gecikme, önbellek isabeti ve guardrail isabeti için özel alanlarla takip ediyor — akışlı yanıtlarda token'lar yanıt tamamlandığında sayılıyor. Dashboard'lar özet göstergeleri ve token/maliyet trendlerini, sağlayıcı ve model payını, guardrail ve önbellek etkinliği raporlarını, kişi/grup/organizasyon birimi/uygulama/model bazlı kullanım kırılımlarını ve canlı bir istek izleme görünümünü gösteriyor. Bkz. APNZ-5128
-
APIops ile Yönetilebilen AI Varlıkları
Her AI varlık tipi — LLM sağlayıcı bağlantıları, AI proxy'ler, MCP ve A2A gateway'leri, knowledge base'ler, vektör veritabanı bağlantıları ve bütçeler — artık normal API proxy'ler ve bağlantılar gibi APIops üzerinden isim bazlı oluşturulup güncellenip silinebiliyor. Giden bir MCP sunucusu ya da A2A ajanı ayrı bir varlık değildir; kendisini kullanan gateway yönlendirmesiyle veya politikayla birlikte tanımlanır. APNZ-5128
-
Identity Management'ta Metadata ve AI Bütçe Kapsamlı Portal Uygulamaları
Portal Uygulamaları artık tüm projelerde adminler tarafından doğrudan Identity Management menüsünden görüntülenip yönetilebiliyor; ayrıca özel bir salt-okunur görüntüleme sayfası, Edit/Delete aksiyonları ve self-service Portal UI ile paylaşılan yeni bir şifreli anahtar-değer Metadata sekmesi eklendi. AI token/maliyet bütçeleri artık, boş bırakıldığında mevcut kurum-geneli bütçeleri bozmadan, tek bir uygulamanın credential'ına kadar daraltılabiliyor. Ayrıca, portal bağlantısı eksik kalan eski Portal Uygulamalarının Manager'da görünürken Portal UI'da görünmez olduğu bir veri-senkron hatası da giderildi. Bkz. APNZ-6419
-
Kimlik Bilgisi Senkronizasyonu
LDAP/Active Directory, Veritabanı ve API kimlik sağlayıcılarındaki kullanıcılar artık zamanlanmış veya elle tetiklenen bir işle otomatik olarak Apinizer kimlik bilgisi kayıtlarına senkronize edilebiliyor; senkronizasyon profili, deaktivasyon modu, durum/geçmiş izleme ve çakışma yönetimi her sağlayıcı ekranından yönetiliyor. Bkz. APNZ-6445
-
API Portal Destek Talepleri
Son kullanıcılar artık API Portal üzerinden doğrudan destek talebi açabiliyor, talep üzerinde mesajlaşabiliyor ve talebi takip edebiliyor. API Manager'a da eşleşen bir admin-taraflı talep gelen kutusu eklendi — liste, detay görünümü, KPI dashboard'u, özelleştirilebilir talep numarası prefix'i ve atanmamış talep sayacı — ayrıca opsiyonel bir Jira durum eşlemesi, talep yaşam döngüsünü (Open, Waiting for Customer, Answered, Resolved) Jira üzerinden yönetebiliyor. APNZ-6468
-
API Portal Ürün, Plan, Katalog ve Uygulama Yönetiminin Yenilenmesi
API Portal yönetimi uçtan uca yenilendi: API ürünlerinde Free / Flat rate / Metered / Tiered plan modeli, sekmelere ayrılmış ürün yönetimi (API'ler, planlar, görünürlük, OpenAPI, abonelikler), sağlayıcıya dönük API Kataloğu, kuruluş üyelik/davet/katılım talepleri, uygulama oluşturma–abonelik–prod terfi sihirbazları ve silme onay akışı eklendi. Yönetim tarafında kuruluşlar arası Trafik ve Kullanım raporu (Kullanım / Trafik sekmeleri, Test-Sandbox / Production ortam anahtarı) ile güncel kota görünümü sunuluyor. Bkz., Bkz. APNZ-6470
-
API Portal API Trafik Raporu
Portal yöneticileri artık Portal → Raporlar → API Trafik Raporu ekranından API ürünü, kurum, hesap ve uygulama bazında portal abonelik trafiğini tablo halinde görüntüleyebiliyor; başarılı, bloklanmış ve hatalı istek sayıları ile min/maks/ortalama yanıt sürelerini tarih aralığı, API ürünü, kurum ve hesap filtreleriyle sorgulayabiliyor. APNZ-5200
-
Bağımlılıklarla Yenilenen Dışa/İçe Aktarma Sihirbazı
Proje menüsünden erişilen yeni Export/Import sihirbazı, API Proxy, Proxy Group, global politika, politika grubu, kimlik bilgisi, LLM Provider, MCP/A2A bağlantıları, knowledge base ve daha birçok nesne tipini bağımlılık ağacıyla birlikte tek pakette dışa aktarmayı; içe aktarımda ise her bağımlılığı hedef projedeki karşılığıyla eşleştirmeyi veya yeni oluşturmayı sağlıyor. Varlık ekranlarındaki Export/Import aksiyonları artık doğrudan sihirbaz akışına yönlendiriliyor; Task Flow, Identity Service, Test Collection (klasör ağacı ve test kayıtları birlikte), Uptime Monitor, Custom Query ve Report Configuration gibi ek varlık tipleri de destekleniyor. Paylaşılan bağımlılıklar tek kopya olarak çözülür, istenmeyen nesneler veya bağımlılıklar paketten çıkarılabilir; Import as New / Replace Existing modları, API Proxy/Proxy Group için Client Route düzenleme ve opsiyonel paket şifreleme (gizli değerler ve nesne adları dahil) desteklenir. Bkz. APNZ-6411, APNZ-6443, APNZ-6450
-
Gateway Idempotency Ayarı
CORS ve Cache ayarları gibi API proxy, proxy group ve Setting Groups üzerinden yapılandırılabilen yeni bir Idempotency Setting eklendi. Yinelenen istekler gateway'de yakalanıyor; aynı anda gelen tekrarlar reddediliyor, tamamlanan istekler saklanan yanıtla yeniden sunulabiliyor — özellikle ödeme ve açık bankacılık akışlarında yeniden deneme veya ağ tekrarı kaynaklı çift işlem riskini azaltmak için. Aynı ayar APIops üzerinden de güncellenebiliyor. Bkz. APNZ-6453
-
JOSE Politikalarında DPoP
JOSE Validation politikası artık gönderene bağlı (sender-constrained) access token doğrulamasını destekliyor; JOSE Implementation politikası da DPoP korumalı üst sistemlere istemci olarak giderken proof üretebiliyor — token çalınsa bile private key olmadan kullanılamaz. Bkz., Bkz. APNZ-6473
-
Standart Kopyalama, Denetim ve Geri Yükleme
API Proxy, politika, bağlantı, kimlik bilgisi, keystore ve diğer birçok varlık türünde Kopyalama (Duplicate), Denetim (Audit) ve Geri Yükleme (Rollback) artık ortak bir yaşam döngüsü aksiyonu olarak sunuluyor: bir kaydı tek tıkla klonlayabilir, değişiklik geçmişini diff görünümüyle inceleyebilir ve gerektiğinde önceki bir yapılandırma anlık görüntüsüne geri dönebilirsiniz. Bkz. APNZ-6309
İYİLEŞTİRMELER-
Backend Ağ Alt-Faz Zamanlama Metrikleri ve Routing Diagnostics Paneli
Gateway artık her backend çağrısı için bağlantı kurma, güvenli bağlantı kurulumu, ilk yanıta kadar geçen süre ve gövde okuma süresini ölçüyor ve bunları mevcut yönlendirme izleme bilgisiyle birlikte kaydediyor. Bu adım adım süreler bir Routing Diagnostics panelinde gösteriliyor; destek ve operasyon ekiplerine, harici bir izleme aracına ihtiyaç duymadan yavaş veya zaman aşımına uğrayan bir backend çağrısının tam olarak nerede takıldığını bulma imkanı veriyor. Bkz. APNZ-6345
-
Backend Routing Adresinde HTTP Metod Override
Her backend routing adresi tanımı artık, isteğin geldiği metodu her zaman ilettiği davranışın yerine, kendi HTTP metodunu isteğe bağlı olarak sabitleyebiliyor. Bu ayar her adres için ayrı uygulanıyor — birincil, canary, sticky, yük dengeleme ve failover adreslerinin her biri kendi değerini kullanıyor — aynalanan trafik ise kendi adres ayarını kullanmaya devam ediyor. Gateway artık HTTP QUERY metodunu da tanıyor: istemciden QUERY ile gelen bir istek, daha önce olduğu gibi hata vermek yerine kabul ediliyor ve gövdesiyle birlikte backend'e iletiliyor. Bkz. APNZ-6430, APNZ-6401
-
Attribution-Zenginleştirilmiş Kota Kullanım Takibi ve Uyarıları
Kota kullanımı artık credential planı, API bazlı kota politikası ve Rate Limit Control List değerlerini periyodik olarak credential, uygulama, ürün/hesap ve kurumuna kadar ilişkilendiriyor. Bu bilgiler hem Kota Kullanımı & Uyarılar tüketim raporunu hem de yapılandırılabilir kota eşiği e-posta uyarılarını besliyor. Bkz. APNZ-6431
-
Key Store, Trust Store ve Key için Export/Import
Key Store ve Trust Store tanımları (JKS/PFX) ile private/public/secret key tanımları artık, sertifikaların zaten yapabildiği gibi, binary dosya veya taşınabilir JSON export olarak dışa/içe aktarılabiliyor. Aynı işlemler APIops'a da eklendi ve Manager UI'da hem Key Store hem de Crypto Key ekranlarına bağlandı. Bkz. APNZ-4959
-
APIops ile API Proxy Deploy Durumu Sorgulama
APIops üzerinden bir API proxy'nin belirli bir ortamda deploy edilip edilmediği ve yeniden deploy gerekip gerekmediği sorgulanabiliyor — otomasyon süreçlerinde deploy öncesi/sonrası kontrol için. Bkz. APNZ-6349
-
APIops ile Route Sağlık Kontrolü, Invoke Bilgisi ve Backend Hata Şablonu Ayarı
APIops üzerinden deploy sonrası route'un sunulup sunulmadığı kontrol edilebiliyor; çağrı bilgisi (adres, yol, metodlar) alınabiliyor; Routing'deki backend hata yanıt şablonu ayarı okunup güncellenebiliyor. Bkz., Bkz., Bkz. APNZ-6350, APNZ-6352, APNZ-6343
-
APIops ile Allowed IP List'te IP Group ve Query Parametre Kodlama
APIops Management API üzerinden Allowed IP List politikasına artık doğrudan IP/CIDR listesinin yanı sıra mevcut IP Group kayıtları da bağlanabiliyor; ayrıca bağlantı ayarlarından backend'e iletilen query parametrelerinin nasıl kodlanacağı seçilebiliyor (Standart, Korumalı, Ham) — Manager'daki Query Parametre Kodlama ayarıyla aynı seçenekler. Bkz., Bkz., Bkz. APNZ-6377, APNZ-6383
-
Hata Hattında Script için Hata Bilgisi
API Proxy hata hattına eklenen Script politikaları artık oluşan hatanın türüne, mesajına, koduna ve HTTP durumuna bakarak farklı davranabiliyor — örneğin yönlendirme hatalarında yanıt dönüşümü uygulayıp politika bloklarında dokunmadan geçmek için. Bkz. APNZ-6381
-
API Promotion'da Bağımlılıkların Promote Edilmesi
API Promotion aktarımlarında kaynak API Proxy veya Proxy Group'un creator bağımlılıkları ile global politika ve sertifika ailesi kayıtları otomatik tespit edilip hedef ortamda eşlenmeli veya yeni oluşturulmalı; böylece yalnızca proxy tanımı değil, çalışması için gereken bağımlılıklar da birlikte taşınabiliyor. Bkz. APNZ-6412
-
Yenilenen Reparse Akışı — Alan Seçimli Üzerine Yazma
API Proxy yeniden ayrıştırma (reparse) sihirbazı yenilendi: kaynak tanımı (WSDL/OpenAPI vb.) yeniden çekildikten sonra yönlendirme adresi, şema, isim ve metod listesi gibi alanlardan hangilerinin üzerine yazılacağını seçebilir; içe aktarma buna göre ilerler. Bkz. APNZ-6444
-
OAuth2/JWT Token Uç Noktalarında Yapılandırılabilir Scope Uyuşmazlığı Davranışı
Credential bazlı ve proxy bazlı OAuth2/JWT akışlarında token üretimi artık, istenen scope eksik olduğunda her zaman hata vermek yerine, merkezi olarak yapılandırılabilir paylaşımlı bir ayar üzerinden scope uyuşmazlıklarını çözüyor. Adminler, isteği tamamen reddetmek yerine istenen ve verilen scope'ların kesişimiyle token verilmesini seçebiliyor; bu, proxy tarafındaki client credentials akışının hiç scope doğrulaması yapmadığı önceki bir boşluğu da kapatıyor. Bkz. APNZ-6232
-
Keystore Studio
Apinizer Toolbox'a, masaüstü KeyStore Explorer'ın tarayıcı tabanlı bir karşılığı olan yeni bir "Keystore Studio" aracı eklendi. Yaygın keystore ve sertifika formatlarını açıp inceliyor, anahtar çiftleri üretiyor, sertifikaları içe aktarıyor ve sonucu doğrudan Apinizer secret havuzuna kaydedebiliyor. Bkz. APNZ-6308
-
Proje Tanımlarında Çoklu Tag ve Tag Bazlı Filtreleme
Projeler artık proje tanım ekranından çoklu serbest-metin etiketlerle (tag) etiketlenebiliyor ve proje seçim popup'ı, kullanıcıların proje listesini bu tag'lere göre filtrelemesine izin veriyor — çok sayıda projesi olan kurumlarda projeleri organize etmeyi ve bulmayı kolaylaştırıyor. Bkz. APNZ-4954
-
SOAP Method Settings'te Opsiyonel WS-Addressing Alanları
SOAP Method Settings'teki WSA Settings bölümü artık kaydetmeden önce her WS-Addressing adres alanının doldurulmasını zorunlu kılmıyor; bu 8 alan artık isteğe bağlı, zorunlu seçimler ve üst seviye SOAP Action ise zorunlu kalmaya devam ediyor. Bkz. APNZ-6247
-
Organization Manager Portal Hesaplarında Aynı E-postayla Tekrarlı Kayıt Engelleme ve Şifre Validasyonu
Organization Manager Portal hesabı oluşturma/düzenleme ekranı artık, girilen e-posta adresi başka bir hesaba aitse Save'i engelliyor; bu kontrol alan düzenlenirken anlık olarak yapılıyor. Form ayrıca şifre karmaşıklığını da zorunlu kılıyor — minimum/maksimum uzunluk ve büyük/küçük harf karışımı. APNZ-5941
-
Log Connector'larında Performans İyileştirmeleri
Webhook, Syslog, Kafka, RabbitMQ ve Database connector'ları ile log yazımında performans iyileştirmeleri yapıldı. APNZ-6482, APNZ-6483
-
API Call ve JOSE Politikalarında Hata Alınırsa Yeniden Deneme
API Call politikası ile JOSE Validation ve JOSE Implementation politikalarının dinamik anahtar çağrıları artık hata alındığında yapılandırılabilir yeniden deneme (retry) uygulayabiliyor; bağlantı hataları ve seçilen HTTP durum kodları için deneme sayısı, bekleme stratejisi ve üst sınırlar politika ekranından yönetiliyor. Bkz., Bkz., Bkz. APNZ-6492
-
API Product Files'ta PDF Yükleme ve Yayında Dosya Silme
API Portal'deki API Product Files sekmesi artık PDF dosyası yüklemeyi destekliyor; yayınlanmış ürünlerde de dosya silme akışı düzgün çalışıyor. Bkz. APNZ-6502
-
API Product ve Portal Setting Export/Import
API Product ve Portal Setting tanımları artık Export/Import sihirbazı üzerinden dışa/içe aktarılabiliyor; portal ürünleri ve portal ayarları da diğer varlıklarla aynı paketleme akışına dahil edilebiliyor. Bkz., Bkz., Bkz. APNZ-6497
-
API Routing'te HTTP/2 Desteği
API routing kısmında HTTP/2 desteği getirildi. Bkz. APNZ-6507
-
RLCL APIops GET ve LIST Endpoint'leri
RLCL (Rate Limit Control List) tanımları artık APIops üzerinden tek tek okunup proje bazında listelenebiliyor. Bkz., Bkz. APNZ-6516
HATA DÜZELTMELERİ-
Kota ve Daraltmada Limite Takılan İsteklerin Sayaca Dahil Edilmesi Düzeltildi
Kota ve daraltma politikalarında limite takılıp reddedilen istekler kullanım sayacını şişirebiliyor; limit sonradan artırılsa bile kalan hak beklenenden az kalabiliyordu. Reddedilen isteklerin sayılıp sayılmayacağı ve limit değişince sayaç davranışı artık ayarlanabiliyor. Bkz., Bkz. APNZ-2452
-
Upgrade Sonrası Allowed IP List Politikalarının Kaybolması Düzeltildi
2025.11.0'dan 2026.04.x'e yükseltmede API Proxy'ye eklenmiş Allowed IP List politikaları kaybolabiliyordu. Proxy'ye doğrudan eklenen politikalar artık korunuyor. Bkz. APNZ-6494
-
Çoklu Portal Ortamında Şifremi Unuttum E-postasının Yanlış Portal Ayarlarıyla Gitmesi Düzeltildi
Birden fazla API Portal tanımlı ortamlarda Şifremi Unuttum akışı, isteğin yapıldığı portal yerine başka bir portalın e-posta ve bağlantı ayarlarını kullanabiliyordu; sıfırlama ve giriş linkleri yanlış portala yönlenebiliyordu. Artık her portal kendi ayarlarını kullanıyor. Bkz., Bkz. APNZ-6409
-
Yüksek Token/Audit Yükünde Worker Pod Restart Sorunu Giderildi
Yoğun token endpoint trafiğinde token ve audit log yazımı worker'ları zorlayıp pod'ların yeniden başlamasına yol açabiliyordu. Log yazımı ve hata loglama bu yük altında tıkanmayacak şekilde iyileştirildi. Bkz. APNZ-6501
-
Credential Listesinde E-posta ile Filtreleme Eklendi
Credential listesinde aynı e-posta adresine bağlı farklı API key'leri ayıklamak için e-posta ile filtreleme yapılamıyordu. Artık e-posta bazlı filtreleme kullanılabiliyor. Bkz. APNZ-6500
-
Cache Politikasında Conditions Kaydının Kaybolması Düzeltildi
Cache politikasında tanımlanan koşullar kaydedilmiyor, politika yeniden açıldığında görünmüyordu. Koşullar artık kalıcı olarak kaydediliyor. Aynı sorun, koşul sekmesi olan ilgili AI politikalarında da giderildi. Bkz. APNZ-6504
-
API Call Politikasının İstenmeden Accept-Encoding Göndermesi Düzeltildi
API Call politikası, Header sekmesinde tanımlı olmasa bile sıkıştırma kabul başlığı gönderebiliyordu. Varsayılan artık kapalıdır; istenirse Ayarlar'dan açılabilir. Bkz. APNZ-6513
-
Update API Proxy'de Deploy Hatasında Yanlışlıkla Undeploy Olması Düzeltildi
Management API ile proxy güncellenirken geçersiz bir ortam verilince hata dönülmesine rağmen proxy yayından düşüyordu. Deploy başarısız olduğunda önceki yayın durumu korunuyor. Bkz. APNZ-6515
-
Expect: 100-continue Başlığının Backend'e Ham Forward Edilmesi Düzeltildi
İstemcinin Continue beklentisi backend'e iletilince hata, bekleme veya protokol sorunu oluşabiliyordu. Bu başlık artık backend'e iletilmiyor. Bkz. APNZ-6509
-
Başarılı DB-2-API Stored Procedure Çağrılarında Yanlış-Pozitif Application Log Hatası Düzeltildi
Try It üzerinden çağrılan başarılı bir DB-2-API stored procedure çağrısı, sonuç başarılı olsa bile Application Logs'ta Error olarak kaydedilebiliyordu. Aynı procedure'ün Try It ve API Proxy çağrıları artık tutarlı şekilde loglanıyor. Bkz. APNZ-6086
-
DB-2-API Duplicate Sonrası Deploy'da Politikaların Kaybolması Düzeltildi
DB-2-API klonlandığında politikalar duplicate ekranında görünüyordu ancak deploy sonrası kaybolabiliyordu. Deploy akışı artık kopyalanan DB-2-API proxy'sindeki politika tanımlarını kalıcı olarak koruyor. Bkz. APNZ-6358
-
Portal'da Düzenlenip Kaydedildiğinde FAQ Kayıtlarının Silinmesi Düzeltildi
Mevcut bir Portal FAQ kaydını düzenleyip kaydetmek, kaydı güncellemek yerine silebiliyordu. Kayıt artık portal ilişkisi korunarak doğru şekilde güncelleniyor. APNZ-6095
-
Yayınlanan Portal Sayfalarında Boş Accordion Kutuları Düzeltildi
Accordion tarzı kutular kullanan HTML içerik sayfaları Manager'ın önizlemesinde doğru görünürken, yayınlandıktan sonra boş kutular gösteriyordu. Yayınlanan sayfalarda accordion içerikleri artık güvenilir şekilde açılıyor. APNZ-6182
-
Portal API Spesifikasyon Örneklerinin JSON Yerine Ham Metin Olarak Görünmesi Düzeltildi
Portal API spesifikasyon sayfalarındaki örnek istek ve yanıt gövdeleri, geçerli JSON yerine okunaksız ham metin olarak görünüyordu. Örnekler artık Manager UI ile aynı şekilde düzgün JSON olarak gösteriliyor. APNZ-6356, APNZ-6364
-
Portal Raporlama ve Dashboard Sorunları Düzeltildi
Portal Reports/Analytics alanında birkaç sorun düzeltildi: aboneliği olmayan tüketici için API test console açıklayıcı bir mesajla kapatılabiliyor; hesap değiştirince dashboard eski veri göstermiyor; çoklu-seçim filtreler doğru etiketleri gösteriyor; kurumlar arası veri sızıntısı kapatıldı. APNZ-6432
-
REST-to-SOAP-to-REST Proxy'lerde Yanlış WSDL Reparse Değişiklik-Önizlemesi Düzeltildi
Bir REST-to-SOAP-to-REST proxy için WSDL'in yeniden ayrıştırılması yanlış tanım çiftini karşılaştırıyor ve hiçbir şey değişmediğinde bile her endpoint'i değişmiş olarak raporlayabiliyordu. Önizleme artık yalnızca istemciye dönük sözleşmeyi karşılaştırıyor ve SOAP operasyonlarını dönüşüm boyunca güvenilir şekilde eşliyor. Bkz. APNZ-5956
-
Politika Sürükle-Bırak Önizlemesinin Yalnızca Üst Yarısını Göstermesi Düzeltildi
API Proxy Flow ekranında bir istek/yanıt/hata politika butonunu yeniden sıralamak için sürüklerken, sürükleme önizleme kutusu görsel olarak kesiliyordu. Sürükleme sırasında imlecin altında artık tam politika kutusu görünüyor. Bkz. APNZ-6056
-
Deploy Geçmişi Sorgusu Nedeniyle Proxy Deploy Hatası Düzeltildi
Deploy geçmişi yüzünden proxy deploy'u başarısız olabiliyordu. Sorun giderildi; deploy güvenilir şekilde tamamlanıyor. APNZ-6300
-
Promotion Modülünde Kaydedilmemiş Mapping'in Otomatik Oluşması Düzeltildi
API Promotion'da mapping oluştururken source API seçildikten sonra Save butonu devre dışı kalsa bile, Save'e basmadan listeye dönüldüğünde mapping kaydı oluşmuş görünüyordu. Mapping artık yalnızca Save ile kalıcı hale getiriliyor. Bkz. APNZ-6379
-
OAuth/JWT Politikalarında Client ID/Secret Düzenleme Akışı Tutarlılığı Düzeltildi
OAuth/JWT politikalarında client id ve client secret alanları policy group, API Proxy Group, global politika ve proxy group içindeki politika ekranlarında API Proxy sayfasındaki gibi düzenlenemiyor veya Automatic/Manual seçimli regenerate akışı sunulmuyordu. Tüm bu ekranlarda artık API Proxy ile aynı düzenleme ve regenerate (Automatic / Manual key generation) davranışı sağlanıyor. Bkz. APNZ-6398
-
JSON→XML ve XML→JSON Dönüşümlerinin Sessizce Uygulanmaması Düzeltildi
JSON ve XML dönüştürme politikalarında dönüşüm bazen sessizce uygulanmıyor veya çıktı yanlış formatta kalabiliyordu. Dönüşüm artık düzgün uygulanıyor; başarısız olursa sessiz geçilmiyor. Bkz., Bkz. APNZ-6484
Davranış değişikliği — dönüşüm hatası artık sessiz geçmiyor. Bu politikalarda dönüşüm başarısız olduğunda istek daha önce ham gövdeyle sessizce ilerliyor ve başarılı görünüyordu. Artık politika hatası üretiliyor; sonuç politikanın Hata Mesajı ayarlarına göre belirleniyor. Aynı değişiklik, dönüşüm aksiyonu kullanan Redaction ve Business Rule politikaları için de geçerlidir. Y ükseltmeden önce, dönüştürülemeyen gövdelerle çalışan bir akışınız olup olmadığını gözden geçirin.
Çıktı formatı değişikliği — JSON→XML kök elemanı. JSON→XML çıktısının kök eleman adı değişti. "Sarmalayıcı elemanı kaldır" seçeneği kullanan yapılandırmalar etkilenmez; eski kök eleman adına göre yazılmış bir alt sistem (XSLT, parser, şema) varsa güncellenmelidir.
Sürüm 2026.04.0
Bu sürüm, platformun tüm bileşenlerinin Java 25'e geçişini, kapsamlı güvenlik sıkılaştırmalarını ve çok sayıda yeni özelliği içeren ana sürümdür.
- Temizleme Görevleri aracılığıyla denetim logları ve ACL denetim loglarının otomatik silinmesi kaldırıldı. Bu loglar uyumluluk açısından kritik öneme sahiptir ve otomatik olarak silinmemelidir. Manuel temizlik scriptleri veritabanı büyüme yönetimi dokümantasyonunda mevcuttur.
- Genel Ayarlar'da denetim ve giriş logları için veritabanına yazımı devre dışı bırakma seçeneği kaldırıldı. Bu loglar artık her zaman veritabanına kaydedilmektedir.
-
Java 25 Geçişi
Apinizer platformunun tüm bileşenleri (API Manager, Gateway Worker, Cache Server, Integration, API Portal) Java 25'e yükseltildi. Sanal thread desteği, modern JDK özellikleri ve performans iyileştirmeleri sağlandı. APNZ-5897
Script Politikası — javax → jakarta Otomatik Dönüşüm: Bu sürümden itibaren, Groovy script politikalarında kullanılan Jakarta EE namespace'leri (örn. javax.servlet.*, javax.persistence.*, javax.xml.bind.*, javax.mail.* vb.) derleme öncesinde otomatik olarak jakarta.* karşılıklarına dönüştürülmektedir. Mevcut script'leriniz bu sürüme geçişte otomatik olarak migrate edilecektir. JDK standart kütüphane paketleri (javax.crypto.*, javax.net.ssl.*, javax.xml.parsers.*, javax.xml.transform.*, javax.script.*) bu dönüşümden etkilenmez ve olduğu gibi kullanılmaya devam eder.
-
Güvenlik Sıkılaştırmaları
Güvenlik taramasında tespit edilen açık içeren bağımlılıklar en güncel sürümlerine yükseltildi. Cross-Site Scripting (XSS), Insecure Direct Object References (IDOR) ve Stack Trace Leak güvenlik açıkları giderildi. innerHTML temizliği, endpoint bazlı proje yetki kontrolü ve hata mesajlarından teknik detay sızıntısı önlendi. APNZ-5736, APNZ-5737, APNZ-5738
-
Elasticsearch 7, 8 ve 9 Tam Desteği
Elasticsearch istemci altyapısı yeniden yapılandırılarak ES 7.x, 8.x ve 9.x sürümleri tam desteklenir hale getirildi. ILM, index template, failover ve tüm analitik ekranları her üç sürümde de test edildi. APNZ-5642, APNZ-5728, APNZ-5898
-
Message Builder Politikası
İstek ve yanıt mesajlarını dinamik olarak oluşturmayı sağlayan yeni bir politika eklendi. JEXL ifade desteği, JSONPath, context variable ve koşullu mantık ile esnek mesaj şablonları oluşturulabilir. Bkz. APNZ-5783
-
Hata Mesajı Özelleştirme
Politikalardaki hata mesajlarının dönüş formatları (JSON/XML) özelleştirilebilir hale getirildi. Her hata tipi için neden bu hatanın oluşabileceği bilgisi eklendi. Tanımsız veya beklenmeyen hatalar için de format seçimi sağlandı. Tekrarlayan ve yakın anlamlı hata mesajları birleştirilerek sadeleştirildi. Bkz. APNZ-5798, APNZ-5940, APNZ-5888
-
API Promotion Modülü
Farklı ortamlar arasında API tanımlarının taşınması ve yönetilmesini sağlayan API Promotion modülü eklendi. Bkz. APNZ-5851