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, APNZ-4729, APNZ-6327, APNZ-3823
İ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, APNZ-5162, APNZ-5059
-
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