Export Import

bilgi

Yenilenen Dışa/İçe Aktarma Sihirbazı, bir nesneyi (API Proxy, Proxy Group, global politika, politika grubu vb.) ve ona bağlı tüm alt kaynakları tek bir pakette dışa aktarmanızı; bu paketi başka bir projeye veya başka bir kurulumdaki Apinizer'a içe aktarırken her bağımlılığı hedef ortamdaki karşılığıyla eşleştirmenizi sağlar. Amaç, bir yapılandırmayı elle yeniden kurmadan, referanslarını kaybetmeden başka bir projeye ya da ortama taşımaktır.

Desteklenen Nesne Tipleri

Sihirbazda dışa/içe aktarılabilecek nesne tipleri yedi kategoride toplanır. Bağımlılık sütunu, o tipin dışa aktarımında ek bir bağımlılık adımı olup olmadığını gösterir:

Kategori	Nesne Tipi	Bağımlılık
API Yönetimi	API Proxy	Var
API Yönetimi	Proxy Group	Var
API Yönetimi	API Creator (DB'den API / Script'ten API / Mock API)	Var
API Yönetimi	Politika Grubu	Var
API Yönetimi	Test Koleksiyonu	Var
Genel Ayarlar	Global Politika	Var
Genel Ayarlar	Ayar Grubu (Settings Group)	Var
Genel Ayarlar	Ortam Değişkeni	Yok
Genel Ayarlar	Global Değişken	Yok
Kimlik	Sertifika / Key Store / Crypto Key / JWK	Yok
Kimlik	IP Grubu	Yok
Kimlik	Kimlik Bilgisi (Credential)	Var
Kimlik	Consumer Rolü	Yok
Kimlik	Kimlik Servisi (LDAP / Veritabanı / API / OIDC Sağlayıcı)	Var
Kimlik	Kayıtlı Organizasyon	Yok
Kimlik	Limit Planı	Yok
Kimlik	API İstemcisi	Var
Kimlik	Limit Ataması	Var
Kimlik	Erişim Yetkilendirmesi	Var
Bağlantılar	Bağlantı (Connection)	Var
İzleme ve Raporlama	Task Flow	Var
İzleme ve Raporlama	Erişilebilirlik İzleme	Var
İzleme ve Raporlama	Anomali Dedektörü	Var
İzleme ve Raporlama	Özel Sorgu	Var
İzleme ve Raporlama	Özel Sorgu Filtresi	Var
İzleme ve Raporlama	Rapor Yapılandırması	Var
AI	LLM Provider	Var
AI	Provider Definition	Yok
AI	Model Definition	Var
AI	Vector DB	Var
AI	Knowledge Base	Var
AI	PII Preset	Yok
AI	Prompt Guard Preset	Yok
AI	DLP Preset	Yok
AI	Prompt Template	Yok
AI	Prompt Decorator	Yok
AI	Topic Category	Yok
Admin	SIEM Ayarları	Var
Admin	API Ürünü	Var

bilgi

MCP sunucusu veya A2A ajanı artık ayrı bir dışa/içe aktarılabilir nesne tipi değildir. Onu gömen politikanın (MCP Çağrısı (LLM) / MCP Araç Çağırma ya da A2A Çağrısı (LLM) / A2A Ajan Çağırma) içinde ve Passthrough modundaki bir MCP/A2A Gateway'inin kendi routing yapılandırması içinde, kendisini içeren API Proxy paketinin bir parçası olarak satır içi taşınır. Eski bir sürümden gelen ve hâlâ ayrı bir MCP/A2A bağlantı nesnesi taşıyan bir paket, sessizce atlanmak yerine içe aktarımda açıklayıcı bir hatayla reddedilir.

Menüden Erişim

Varlık bazlı Dışa/İçe Aktarma sihirbazına iki yerden ulaşılır: proje menüsündeki Dışa/İçe Aktar grubu ve Administration → Dışa/İçe Aktar grubu. Administration grubu ayrıca bütün proje paketini kapsayan iki sayfayı da içerir:

• Proje Dışa Aktar — bir projenin tamamını tek ZIP olarak dışa aktarır. Sayfada proje, yetki-filtreli listeden açıkça seçilir (yalnızca PROJECT_MANAGEMENT / EXPORT_IMPORT yetkinizin olduğu projeler listelenir); varsa aktif proje yalnızca ön-seçili gelir ve proje seçilmeden Dışa Aktar butonu pasif kalır. Bu yüzden giriş aktif proje gerektirmez; menü ve sayfa aynı PROJECT_MANAGEMENT / EXPORT_IMPORT yetkisini ister (sistem yöneticisi her zaman geçer). Hiçbir projede bu yetkiniz yoksa liste yerine açıklayıcı bir boş-durum metni gösterilir.
• Proje Yükle — bütün proje paketini içe alarak yeni bir proje oluşturur. Yeni proje oluşturduğu için aktif proje gerektirmez ve yalnızca sistem yöneticisine görünür. Aynı sayfaya Administration → Projects ekranındaki butondan da ulaşılabilir.

Bütün proje paketi, varlık bazlı sihirbazın tip kataloğunda yer almaz; bilinçli bir kapsam ayrımıdır — proje paketi yeni proje oluşturma ve paket inceleme gibi farklı bir semantik taşır.

OTLP Bağlantı Ekranındaki Basit İçe Aktarma

OTLP, sihirbazın Bağlantı (Connection) kataloğuna hiç girmeyen tek bağlantı tipidir; kendi liste ekranında, sihirbazın adımlarından bağımsız, tek adımlı bir İçe Aktar diyaloğu taşımaya devam eder — yalnızca dosya seçilir, Import as New ya da Replace Existing arasında seçim yapılır ve doğrudan içe aktarılır. Diğer 14 bağlantı tipinin (Kafka, Webhook, E-posta, Syslog, Graylog, RabbitMQ, DB Pool, Elasticsearch, SNMP, FTP, ActiveMQ, Linux Script, Logback, LDAP Pool) liste ekranlarında bu ayrı diyalog artık YOK: araç çubuğundaki İçe Aktar düğmesi doğrudan sihirbazın kendi Bağlantı (Connection) içe aktarma adımını, tip Bağlantı ön-seçili olarak açar (bkz. bir sonraki bölüm) — Administration ekranından açıldığında kapsam Admin'dir. Şifreli bir paket OTLP'nin diyaloğundan da içe aktarılabilir: seçilen dosya parola korumalıysa ilk Import denemesinden sonra diyalog parola alanını açar — paketin dışa aktarılırken verilen parolasını girip Import düğmesine yeniden basmanız yeterlidir. Yanlış parola satır içinde bildirilir; dosyayı yeniden seçmeden düzeltebilirsiniz.

Bu diyalog artık, sihirbazın özet adımıyla aynı şekilde, hedefte çözülemeyip düşürülen referansları ve üzerine yazılan sağlayıcı secret'larını aynı uyarı metinleriyle ekranda bir sonuç bloğu olarak gösterir; önceden bu bilgi yalnızca sunucu log satırına düşerdi.

Sihirbazda Bağlantı (Connection) Nesne Tipi

Bağlantı (Connection), sihirbazın Bağlantılar kategorisi altında kendi başına dışa/içe aktarılabilen bir ana nesne tipidir. Kapsadığı bağlantı tipleri: Veritabanı Havuzu, Kafka, Elasticsearch, E-posta, FTP, Graylog, Syslog, RabbitMQ, ActiveMQ, Webhook, Logback, SNMP, LDAP Havuzu ve Linux Script — bu 14 liste ekranının tümünde satır menüsünün birincil Export eylemi ve araç çubuğundaki Import düğmesi artık doğrudan bu sihirbaz tipini, ilgili bağlantı ön-seçili olarak açar (proje kapsamında, Administration'dan açıldığında Admin kapsamında). Tek istisna için yukarıdaki OTLP bölümüne bakın.

• Sertifika bağımlılığı birlikte taşınır: Kafka ve Syslog'un key store'u ile trust store'u, Webhook'un key store'u ile trust store'u, LDAP Havuzu'nun sertifikası ve E-posta bağlantısının sertifikası, bu tipin bağımlılık adımında otomatik olarak yüzeye çıkar ve pakete dahil edilebilir — yukarıdaki Mapping & Dependencies bölümünde anlatılan sertifika eşlemesiyle aynı şekilde çözülür. Bir bağlantının host/URL/parola alanındaki ${DEĞİŞKEN} referansları da aynı şekilde ortam ya da global değişken bağımlılığı olarak taşınır.
• OTLP bu tipin dışındadır: OpenTelemetry (OTLP) bağlantısı bu kataloğa girmez, kendi ayrı yolunda kalır — kendi admin ekranındaki içe aktarma diyaloğuyla dışa/içe aktarılmaya devam eder.
• "Export as File" (Dosya Olarak Dışa Aktar) düğmesinden farkı: bu 14 ekranda satır menüsünün ikincil Export as File kalemi (bu tip var olmadan önceki ham tek-dosya ZIP yeteneği, korunarak buraya indirildi) bağımlılık taşımaz — sertifika ya da key store olmadan yalnızca bağlantının kendi alanlarını dışa aktarır. Sertifikayı bağlantıyla birlikte taşımanız gerekiyorsa (örn. mTLS sertifikalı bir LDAP havuzu) satır menüsünün artık birincil olan Export eylemi — yani bu sihirbaz tipi — bunu zaten varsayılan olarak yapar.

Erişim, diğer tipler gibi proje menüsündeki Dışa/İçe Aktar grubu ve Administration → Dışa/İçe Aktar üzerindendir; yetki kategorisi Bağlantılar'dır.

Kullanım Akışı

Akış, seçtiğiniz nesne tipinin bağımlılık taşıyıp taşımadığına göre otomatik şekillenir:

• Bağımlılığı olan tipler (API Proxy, Proxy Group, API Creator, Global Politika, Politika Grubu, Ayar Grubu, Test Koleksiyonu, Kimlik Bilgisi, Kimlik Servisi, Bağlantı, LLM Provider, Model Definition, Vector DB, Knowledge Base, API İstemcisi, Limit Ataması, Erişim Yetkilendirmesi, Task Flow, Erişilebilirlik İzleme, Anomali Dedektörü, Özel Sorgu, Özel Sorgu Filtresi, Rapor Yapılandırması, SIEM Ayarları, API Ürünü) sihirbazın tam adımlarından geçer: nesne(ler) seçilir, bağımlılık ağacı çözümlenir, dışa aktarımda hangi bağımlılıkların pakete dahil edileceği seçilir; içe aktarımda ise her bağımlılık hedef projedeki karşılığıyla eşleştirilir. Seçilen kayıtların hiçbir bağımlılığı çözümlenmediyse (örn. bir Model Definition hiçbir özel sağlayıcı tanımına referans vermiyorsa, bir Vector DB bağlantısı hiçbir ortam değişkeni kullanmıyorsa ya da bir API İstemcisi bir uygulamaya aitse) bu adımda açık bir "bağımlılık bulunamadı" boş-durum mesajı gösterilir.
• Bağımlılığı olmayan tipler (Ortam Değişkeni, Global Değişken, Sertifika ailesi, IP Grubu, Consumer Rolü, Kayıtlı Organizasyon, Limit Planı, Provider Definition, PII Preset, Prompt Guard Preset, DLP Preset, Prompt Template, Prompt Decorator, Topic Category) için ek bir bağımlılık/eşleştirme adımı yoktur — nesne seçildiği anda doğrudan dışa aktarılır; içe aktarımda ise dosya yüklendiği anda doğrudan seçeneklere (Options) geçilir.

Dışa Aktarma

Tip Seç

Dışa aktarılacak nesne tipini (API Proxy, Global Politika, Kimlik Bilgisi vb.) seçin.

Nesne(leri) Seç

Projedeki nesneler listelenir; birden fazla nesne aynı anda işaretlenebilir.

Bağımlılıklar (varsa)

Seçilen nesne(ler)in kullandığı global politika, ayar grubu, sertifika, IP grubu, kimlik bilgisi, ortam/global değişken ve API Creator bağlantıları otomatik taranır. İstenmeyen bağımlılıkların işareti kaldırılabilir. Bir uyarı taraması (sertifika süresi, secret hatırlatmaları, eksik ortam değişkenleri) burada gösterilir.

Özet ve İndirme

Pakete dahil edilecek içerik özetlenir, dosya adı verilir ve paket ZIP olarak indirilir.

Bu adımdaki Paket Şifreleme (opsiyonel) başlığı altında pakete bir parola verebilirsiniz. Parola girdiğinizde bir Parola (tekrar) alanı görünür; iki alan birbirini tutmazsa Parolalar eşleşmiyor. uyarısı çıkar ve indirme düğmesi devre dışı kalır. Parola verilen paketin tamamı — içindeki nesne adları dahil — şifrelenir. Alanı boş bırakırsanız paket eskisi gibi düz üretilir.

Parola hiçbir yerde saklanmaz ve kurtarılamaz; kaybederseniz paket bir daha içe aktarılamaz.

İçe Aktarma

Tip Seç

İçe aktarılacak nesne tipini seçin. Yüklenen paket seçilen tiple uyuşmuyorsa sihirbaz paketin gerçek içeriğini tespit eder ve doğru tipi seçmeniz için uyarır.

Paketi Yükle

Export edilmiş ZIP/JSON dosyası yüklenir; paket içeriği (ana nesne, varsa üye API Proxy'ler, bağımlılıklar) analiz edilip listelenir.

Seçtiğiniz paketin şifreli olduğu otomatik olarak tespit edilir; bu durumda Bu paket şifreli başlığıyla bir parola alanı ve Kilidi aç düğmesi çıkar. Paket ancak kilidi açıldıktan sonra analiz edilir, dolayısıyla doğru parola girilmeden içeriği listelenemez. Yanlış parolada paket açılmaz — parola alanı temizlenir ve satır içi bir uyarı ile tekrar deneyebilirsiniz.

Eşleştirme (varsa)

Paketteki her bağımlılık hedef projedeki aynı türden mevcut bir nesneyle eşleştirilir; hedefte karşılığı yoksa pakette gelen tanımdan yeni bir nesne oluşturulabilir. Çoklu nesne içeren paketlerde istenmeyen nesneler içe aktarımdan çıkarılabilir.

Seçenekler

Import as New (yeni nesne olarak oluştur) ya da Replace Existing (hedefteki mevcut bir nesneyi tamamen güncelle) arasında seçim yapılır. API Proxy/Proxy Group için Client Route (relative path, host, metod, header) burada düzenlenebilir.

Import as New, kullanımda olan bir ismi reddeder ve hatada üç durumdan hangisi olduğu belirtilir: isim hedef projede zaten vardır (Replace Existing seçilir ya da burada yeniden adlandırılır), paketin kendisi aynı türden nesneler için aynı ismi iki kez taşımaktadır (kopyalardan biri yeniden adlandırılır) ya da isim bu kurulumda başka bir yerde kullanılmaktadır. Son durum, adları tüm projeler genelinde benzersiz olmak zorunda olan nesne türleri için geçerlidir — kimlik bilgisi kullanıcı adları, ortam değişkenleri, AI hazır ayar katalogları ve model tanımları — bu yüzden hedef projede nesne görünmese bile içe aktarma reddedilebilir; isim başka bir projeye, paylaşılan (admin) kapsama ya da yerleşik (built-in) bir kayda ait olabilir. Bu durumda Replace Existing seçeneğinin bu projede güncelleyeceği bir kayıt yoktur; nesneyi içe aktarmadan önce yeniden adlandırın ya da ismin sahibi olan projeye aktarın.

Replace Existing nesnenin kimliğini korur: hedefteki kaydın kimliği, API Proxy ve Proxy Group'un istemci doğrulamasında kullanılan anahtar/secret çifti ve Policy Group'un çalışma zamanı anahtarı olduğu gibi kalır; paketten gelen kaynak kurulumun anahtarları hiçbir zaman hedefe yazılmaz. Deploy durumu da korunur: hedefte deploy edilmiş her ortam "redeploy gerekli" olarak işaretlenir, çünkü içerik değişmiştir ve Gateway hâlâ eski tanımı sunar — değişikliğin devreye girmesi için ilgili ortama yeniden deploy edin. Import as New ile oluşan nesne ise yeni kimlik ve anahtarlarla, hiçbir ortama deploy edilmemiş olarak başlar; import hiçbir durumda kendiliğinden deploy yapmaz.

Test Koleksiyonu Replace işleminde testler taşınabilir test kimliğiyle eşleştirilir. Eşleşen test hedefteki MongoDB kimliğini ve oluşturulma tarihini korurken taşınabilir içeriği güncellenir; yeni kimlik yeni test olarak eklenir. Varsayılan Birleştir ve koru modu yalnız hedefte bulunan testleri korur. Tam değiştir yalnız İçe Aktarma Sihirbazı'nda kullanılabilir: silinecek doğrudan testlerin kesin listesini gösterir ve açık onay ister. Seçilen koleksiyon önizlemeden sonra değişirse hiçbir kayıt yazılmadan işlem reddedilir ve paket yeniden analiz edilmelidir. Tam değiştirme alt koleksiyonları, kardeş koleksiyonları veya bunların testlerini asla silmez. Taşınabilir test kimliği taşımayan eski paketler desteklenmeye devam eder; eski paket satırından kararlı bir kimlik türetilir ve aynı paketin ikinci aktarımı hedefteki aynı testi günceller.

Kimlik bilgisi (credential) içe aktarılırken kaynak kurulumdaki organizasyon, sertifika/keystore/truststore, kripto anahtarı ve JWK referansları ile kimlik doğrulama servisi (LDAP, veritabanı, API, OIDC sağlayıcı, JWT yenileme API'si), rol, Portal uygulaması/hesabı ve ortama özel ayrıntı (ortam bazlı parola ve IP listesi) referansları hedefte bulunamazsa alan boş bırakılır (liste alanlarında yalnızca bulunamayan öğeler çıkarılır) ve bu durum içe aktarma özetinde bir uyarı olarak listelenir; Replace Existing seçildiyse hedefteki mevcut geçerli referans, çözülemeyen paket değerinin yerine korunur ve bu koruma da aynı özette belirtilir. Portal uygulaması referansında ölçüt organizasyondur: uygulama yalnızca kimlik bilgisi hedef projenin kullanabildiği bir organizasyon taşıyorsa (o projeye ya da admin projesine kayıtlı bir organizasyon; kimlik bilgisi ekranındaki organizasyon seçicisinin sunduğu kümenin aynısı. Başka bir projeye kayıtlı organizasyon, kimliği bilinse bile kabul edilmez) ve uygulama da aynı organizasyona aitse korunur; başka bir organizasyona ait bir uygulama, kaydı gerçek olsa da bulunamamış sayılır ve organizasyonu çözülemeyen bir kimlik bilgisi hiçbir uygulama referansı taşımaz (doğrulanacak bir şey yoktur). Uygulamanın projesi bilerek denetlenmez (Portal, bir uygulamaya proje bilgisini yalnızca tek proje sunduğu sırada yazar ve sonradan güncellemez); bu yüzden admin projesine, başka bir projeye ait ya da projesi hiç olmayan uygulamalar, organizasyon eşleştiği sürece kabul edilir. Yönetici tarafından oluşturulan dahili (internal) uygulamaların organizasyonu yoktur; bunlar projesi boşsa, admin projesiyse ya da içe aktarılan projenin kendisiyse korunur. Portal hesabı referansı bir sahiplik değil atıf bilgisidir: korunan bir uygulama varsa hesabın yalnızca aynı portalda var olması yeterlidir; uygulama yoksa hesabın var olması ve kimlik bilgisinin organizasyonuna birincil organizasyon ya da etkin üyelik ile bağlı olması gerekir. Bu denetimlerden geçemeyen referanslar da yukarıdaki gibi boş bırakılıp içe aktarma özetinde uyarı olarak listelenir. Replace Existing seçildiğinde içe aktarma kimlik bilgisinin organizasyonunu hiçbir zaman değiştirmez: paket ne taşırsa taşısın hedef kendi organizasyonunu korur, farklı organizasyon taşıyan paket özette belirtilir. Organizasyon değişikliği tüketicinin Transfer işlemiyle yapılır; bu işlem organizasyonu izleyen API istemcilerini, erişim kayıtlarını ve token'ları da birlikte taşır. Hedefteki mevcut uygulama ve hesap da aynı denetimlerden geçer ve yalnızca geçerlerse korunur; uygulama ya da hesap referansı taşımayan bir paket, hedefin doğrulanmış uygulama ve hesabını korur ve bu karar da özette belirtilir. Bu davranış yalnızca organizasyon ile Portal uygulaması/hesabı için geçerlidir. Diğer tüm referanslar (sertifika, keystore, truststore, kripto anahtarları, JWK, kimlik doğrulama servisi, roller, ortama özel ayrıntılar) Replace Existing'de paketi izler: paket böyle bir alan için değer taşımıyorsa hedefteki değer uyarı verilmeden silinir; kimlik bilgisini o alan boş kaydetmekle aynı sonuçtur. Kaynak kurulumun kimlik numarası hiçbir zaman olduğu gibi kaydedilmez.

Bir Kimlik Servisi (LDAP / Veritabanı / API / OIDC Sağlayıcı bağlantısı) içe aktarılırken, o bağlantının en son senkronizasyon koşusuna ait durum bilgisi — son koşunun sonucu, bekleyen bir elle tetikleme isteği ya da o an bir koşunun sürdüğü iddiası — kuruluma özeldir ve paketle birlikte taşınmaz. Import as New bu durumu boş başlatır: yeni bağlantı hiç senkronize edilmemiş gibi görünür. Replace Existing hedefteki mevcut durumu korur; paket bu alanları hiçbir zaman ezmez. Paket analiz edildikten sonra, siz içe aktarmayı onaylamadan önce hedefte bir senkronizasyon koşusu çalışıp bu durumu değiştirirse, içe aktarma "Bu paket analiz edildikten sonra hedef değişti. Eşleme ve değiştirme seçimlerinin güncel duruma göre yapılabilmesi için analizi yenileyin. Hiçbir kayıt içe aktarılmadı." mesajıyla reddedilir — bu durumda paketi yeniden analiz edip tekrar deneyin.

Özet ve İçe Aktarma

Hangi nesnenin oluşturulacağı, hangisinin eşleştirileceği özetlenir; onaylandığında içe aktarım uygulanır.

İçe aktarma, paketin analiz edildiği andaki hedef durumuna karşı uygulanır. Analizden sonra hedef projede eşleştirme veya değiştirme seçimlerini etkileyen bir değişiklik olduysa (örneğin başka bir sekmede aynı adda bir nesne oluşturulduysa) içe aktarma hiçbir kayıt yazmadan "Bu paket analiz edildikten sonra hedef değişti" uyarısıyla durur; paketi yeniden yükleyip analizi tekrar çalıştırmanız yeterlidir. Eşleştirme adımındaki Oluştur düğmesiyle yaptığınız oluşturmalar bu uyarıyı tetiklemez: sihirbaz her oluşturmadan sonra analizi arka planda tazeler. Bir bağımlılık satırında Oluştur'a bastığınızda, oluşturulan nesnenin yanında bu projede kendiliğinden meydana gelen başka nesneler de olabilir (örneğin bir MCP ağ geçidinin kaynak API Proxy'si oluşturulduğunda o proxy'nin kendi politika grubu ve global politikaları). Sihirbaz yalnızca bu oluşturma işleminin ürettiği nesneleri, henüz eşlenmemiş satırlara otomatik olarak bağlar; böyle bağlanan satırda Eşleme adımında "Otomatik eşlendi" rozeti ve üzerine gelindiğinde bunu açıklayan bir ipucu görünür. Hedef projede zaten var olan aynı adlı bir nesneye ASLA otomatik bağlanmaz: bilerek boş bıraktığınız satır boş kalır ve o referans içe aktarımda düşürülür. Otomatik eşlenen satırlar İnceleme tablosunda "Otomatik eşlendi" etiketiyle, İçe Aktar onay penceresinde ve içe aktarım sonuç ekranında ayrı bir listede gösterilir. İstemiyorsanız listeden farklı bir hedef seçmeniz yeterlidir; seçim yaptığınız anda rozet kalkar.

Paket Şifreleme

Şifreleme opsiyoneldir ve varsayılan olarak kapalıdır. Parola vermediğiniz paketler eskisi gibi üretilir ve önceki Apinizer sürümleriyle uyumlu kalır; şifrelemeyi kullanmaya başlamak için mevcut akışınızda hiçbir değişiklik yapmanız gerekmez.

Dışa aktarma sihirbazının son adımında bir parola verdiğinizde paketin tamamı şifrelenir. Bu koruma yalnızca paketin içindeki gizli değerleri değil, paketteki nesne adlarını da kapsar — paketi eline geçiren biri dosyanın dışından içeriği hakkında hiçbir şey anlayamaz; hangi proxy'lerin, sertifikaların ya da politikaların taşındığını dahi göremez.

Şifreleme anahtarı doğrudan sizin parolanızdan türetilir. Parolanın kendisi pakete yazılmaz ve Apinizer tarafında da saklanmaz; paketi açabilecek tek şey, dışa aktarım sırasında girdiğiniz parolanın aynısıdır.

uyarı

Parola kurtarılamaz. Apinizer parolayı saklamadığı için unutulan ya da kaybedilen bir parolayı sıfırlamanın veya paketten geri çıkarmanın yolu yoktur — paket bir daha içe aktarılamaz.

Paketi ve parolayı ayrı kanallardan paylaşın. Paketi e-posta ile gönderip parolayı da aynı e-postaya yazmak, şifrelemenin sağladığı korumayı ortadan kaldırır.

Ne Zaman Kullanmalı

Şifrelemeyi özellikle şu durumlarda tercih edin:

• Paket, sertifika özel anahtarı ya da key store parolası gibi gizli değerler taşıyorsa.
• Paket e-posta, dosya paylaşım servisi ya da ortak bir dizin gibi güvenli olmayan bir kanaldan geçecekse.

Paketin yalnızca güvenli bir ortamda kaldığı ve gizli değer taşımadığı durumlarda parola vermeden devam edebilirsiniz.

APIops Üzerinden Şifreleme

Aynı şifreleme, dışa/içe aktarımı APIops üzerinden otomatikleştirdiğinizde de kullanılabilir; sihirbazda ürettiğiniz şifreli bir paketi APIops ile içe aktarabilir ya da tersini yapabilirsiniz. Parametre ve istek başlığı ayrıntıları için ilgili API Referansı sayfalarına bakın: API Proxy Dışa Aktar, API Proxy İçe Aktar, Anahtar Dışa Aktar ve Key Store Dışa Aktar.

Paket Bütünlüğü

Apinizer'ın ürettiği her paket, kendi içeriğinin kaydını taşır: pakete apinizer-transfer-manifest.json adlı fazladan bir dosya konur ve bu dosya pakette hangi dosyaların bulunduğunu, her birinin ne olduğunu ve her birinin parmak izini listeler. İçe aktarma sırasında Apinizer bu parmak izlerini yeniden hesaplar ve hedefe hiçbir şey yazmadan önce kayıtla karşılaştırır.

• Paket, Apinizer'ın ürettiği hâliyle geldiyse eskisi gibi içe aktarılır; kontrolü fark etmezsiniz bile.
• Paketin dışa aktarımdan sonra değiştiğini gösteren bulgular artık içe aktarmayı kendiliğinden bitirmez; tek bir onayla geçilebilir. Bu onayın kapsadığı üç durum şudur: pakette bulunan bir dosyanın içeriği değişmiştir (parmak izi kayıtla tutmaz); pakete dosya eklenmiş ya da paketten dosya çıkarılmıştır; bütünlük kaydının kendisi okunamaz durumdadır ya da paketteki dosyalarla tutarsızdır. Üçünde de karar sizindir: onaylarsanız içe aktarma paket geldiği hâliyle sürer, onaylamazsanız işlem burada durur ve hiçbir kayıt yazılmaz. Okunamaz bir bütünlük kaydını onayladığınızda paket, kayıt hiç yokmuş gibi içe aktarılır.
• Onayın nasıl istendiği ekrana göre değişir. Sihirbazda ayrı bir pencere açılmaz: fark, adımın üzerinde bir uyarı satırı olarak görünür ve içe aktarma devam eder. Sihirbaz dışındaki tek dosyalı Import diyaloglarında — bir bağlantı tipinin liste ekranındaki diyalog ve bir API Proxy ya da API Proxy Grubunun politika Import diyaloğu (bir politika paketini yerel politika olarak içe aktarır) — Paket İçeriği Değişmiş başlıklı bir onay penceresi çıkar; onayladığınızda paket fark kabul edilerek yeniden açılır. Şifreli bir paketin parolası da bu diyaloglarda aynı biçimde, ilk denemeden sonra açılan satır içi alanla istenir. Yönetim → Projeler → Projeyi İçe Aktar ekranı da aynı onay penceresini gösterir; orada paket, proje oluşturulmadan önce denetlenir, dolayısıyla onaylamadığınız bir paket arkasında boş bir proje bırakmaz.
• Onayla tamamlanan içe aktarma iz bırakır: işlem sonunda kaç dosyanın kayıtla uyuşmadığını söyleyen bir uyarı görürsünüz, onayı veren kullanıcı ise hangi paketi hangi tarihte onayladığı bilgisiyle birlikte uygulama günlüğüne (operasyonel log) yazılır. Bu kayıt Denetim Kayıtları ekranında görünmez, yalnızca uygulama günlüğündedir.
• Bütünlük kaydı hiç bulunmayan paket engellenmez. Önceki Apinizer sürümlerinden dışa aktarılmış paketler böyle bir kayıt taşımaz ve eskisi gibi içe aktarılmaya devam eder; sihirbaz, bağlantı liste ekranındaki Import diyaloğu ve Projeyi İçe Aktar ekranı bu durumda "bu pakette bütünlük kaydı yok" uyarısını gösterir. Politika Import penceresi bu uyarıyı göstermez; orada paket sessizce içe aktarılır.
• Onayla da geçilemeyen durumlar, paketin değişmiş olmasıyla değil uyumlulukla ilgilidir: paket bu kurulumun tanımadığı yeni bir bütünlük kaydı biçimi taşıyorsa, tanımadığı kritik bir özellik bildiriyorsa ya da desteklenmeyen bir parmak izi yöntemiyle üretilmişse içe aktarma yarım okunmak yerine net bir mesajla reddedilir. Paketin içindeki bir dosyanın kendisi okunamıyorsa — örneğin bir metin düzenleyici tırnak işaretlerini akıllı tırnakla değiştirmişse — dosya gerçekten çözümlenemediği için bu da onaylanamaz.

bilgi

Bu onay, paketin kimin ürettiğini değil, yalnızca dışa aktarımdan sonra değiştiğini bilerek devam ettiğinizi kaydeder. Onayı verdiğinizde içe aktarılan nesneleri işlem sonrasında gözden geçirin: farkı Apinizer üretmemiştir.

ipucu

Windows'ta bir metin düzenleyiciyle açılıp kaydedilen paket dosyaları (dosya başına eklenen görünmez işaret ve satır sonu biçimi değişikliği) artık içe aktarmayı bozmaz — fark onaylandığında işlem sonuna kadar tamamlanır.

uyarı

Dışa aktarma dosyasını açıp içindeki bir dosyayı düzenleyip yeniden sıkıştırmaya dayanan bir akışınız varsa, o paket artık otomatik olarak içe aktarılmaz — içe aktarımı tamamlamak için yukarıdaki onayı vermeniz gerekir. Mümkünse değişikliği kaynak kurulumda yapıp paketi yeniden dışa aktarın ve Apinizer'ın ürettiği dosyayı olduğu gibi kullanın; bu, onay adımına hiç ihtiyaç duymadan sürdürmenin en güvenli yoludur.

İçeriğe hiç dokunmadan yapılan yeniden paketleme çalışmaya devam eder — kontrol, arşivin nasıl kurulduğuna değil, her dosyanın kendi içeriğine bakar. Yine de özgün dosyayı kullanmayı tercih edin: bazı araçlar yeniden sıkıştırma sırasında dosyaları değiştirir.

APIops üzerinden içe aktarımda aynı onay bir istek parametresidir — yukarıdaki üç durumun hepsini kabul eder. Parametre ve yanıtın geri taşıdığı uyarı için bkz. Import Objects.

Pakete Giremeyen Nesneler

Paket üretilirken bir nesne pakete yazılamazsa dışa aktarma geri kalan her şey için tamamlanır — ancak eksik kalan nesnenin adı, iz bırakmadan kaybolmak yerine artık paketin içerik kaydına yazılır. Bir pakette seçtiğiniz nesnelerden biri eksik görünüyorsa paketin içindeki kayıt dosyasını açın: pakete giremeyen nesneler orada adlarıyla listelenir.

Gizli Materyal Taşıyan Paketler

Bazı nesne tipleri gizli değerlerini paketin içinde okunabilir hâlde taşır — örneğin bir AI sağlayıcısının API anahtarı, bir key store parolası ya da bir sertifikanın özel anahtarı. Bir Uptime Takibi, Anomaly Detector, Task Flow Manager ya da Rapor Üretici paketi bir gizli değer daha taşır: içindeki bir bildirim konnektörünün kendi gizlilik ayarı açıksa, o konnektörün maskeleme/hash kurallarının arkasındaki tuz da pakette düz metin olarak taşınır — bir SIEM hedefinin gizlilik tuzuyla aynı şekilde (bkz. aşağıdaki SIEM Ayarları). Böyle bir nesne pakete girdiğinde dışa aktarma sihirbazı, dosyayı indirmenizden önce sizi uyarır ve hangi nesnelerin söz konusu olduğunu adlarıyla belirtir; uyarı değerlerin kendisini hiçbir zaman göstermez.

Böyle bir dosyayı içindeki gizli değerlerle aynı özenle saklayın; dosya güvenli ortamın dışına çıkacaksa parola vererek dışa aktarın — bkz. yukarıdaki Paket Şifreleme.

Eski Paketler Artık İçe Aktarılamaz

LLM Provider, Vector DB ve OpenTelemetry (OTLP) bağlantısı gibi tipler, gizli değerlerini pakete okunabilir olarak yazar; içe aktarma da onları hedef kurulumda yeniden şifreler. Bu davranıştan önce üretilmiş çok eski paketler ise aynı alanları şifrelenmiş hâlde taşır. Böyle bir paket içe aktarıldığında değer ikinci kez şifrelenir ve geri döndürülemez biçimde kullanılamaz hâle gelir — üstelik işlem başarılı görünür, sorun ancak sağlayıcı ilk kez çağrıldığında ortaya çıkar.

Bu sürümden itibaren bu paketler sessizce bozulmak yerine reddedilir: içe aktarma durur ve paketin güncel bir Apinizer sürümüyle kaynak kurulumdan yeniden dışa aktarılması gerektiğini söyleyen bir hata alırsınız. Yapmanız gereken, paketi kaynak kurulumda yeniden üretmektir; elinizdeki eski dosya üzerinde yapılabilecek bir düzeltme yoktur.

Bağlantı tanımları (e-posta, LDAP, veritabanı, SNMP, Elasticsearch, FTP, RabbitMQ, ActiveMQ, Linux Script) ile kimlik servisleri bu kuralın dışındadır: onların gizli değerleri pakette şifreli taşınır ve hedefte olduğu gibi saklanır. Bu tiplerde bir paket gizli değeri düz metin taşıyorsa — örneğin elle yazılmış bir GitOps dosyası, ya da çok eski bir sürümde düz metin kaydedilmiş bir kayıttan üretilmiş bir paket — içe aktarma artık o değeri hedefte şifreleyerek saklar. Yükseltme sırasında çalışan bir veri düzeltmesi, daha önce düz metin kaydedilmiş bu değerleri de şifreler; zaten şifreli olanlara dokunmaz.

uyarı

Bütünlük kaydı, paketin kazara bozulmadığını ya da değiştirilmediğini gösterir. Paketi kimin ürettiğini kanıtlamaz: kayıt paketin içinde taşındığı için, paketi değiştirebilen taraf kaydı da yeniden yazabilir.

Bu güçlü garantiyi yalnızca parolayla dışa aktarma verir — parola olmadan açılamayan bir paket, parola olmadan değiştirilemez de.

İçe Aktarma Yetkileri ve Sınırları

Sihirbaz Ekranına Kimler Girebilir

Toplu Aktar ekranları (Dışa Aktar ve İçe Aktar), aktif projenizde şu kategorilerden en az birinde Export/Import yetkisi ister: Proje Yönetimi, API Yönetimi, Global Ayarlar, Kimlik, Gizli Bilgiler, Bağlantılar, API Oluşturucu, AI Geliştirme, AI Bütçeleri, AI Analitik.

Proje yöneticileri ve sistem yöneticileri her zaman girebilir. Administration menüsündeki Export/Import girişleri sistem yöneticisine bir proje aktifken gösterilir; yalnızca Proje Yükle sayfası aktif proje gerektirmez (projeyi kendisi oluşturur). Bu kategorilerin hiçbirinde Export/Import yetkisi olmayan bir kullanıcı — örneğin yalnızca Analitik yetkisi olan bir proje üyesi — ekranı menüde göremez ve adres çubuğuna yazarak da açamaz; erişim yok sayfasına yönlendirilir. Sertifika, KeyStore, Consumer, Bağlantı ve API Oluşturucu listelerindeki İçe Aktar kısayol düğmeleri de aynı yetkiye bağlıdır: yetkiniz yoksa düğme görünmez, böylece boş ekrana götüren bir kısayol kalmaz. OTLP dışındaki 14 bağlantı liste ekranında bu düğme, tip Bağlantı ön-seçili olarak sihirbazın içe aktarma adımını açar — Administration'dan açıldığında Admin kapsamında, aksi halde aktif projenin kapsamında.

Ekrana girebilmek, hangi nesneleri aktarabileceğinizi belirlemez — onu aşağıdaki kurallar belirler ve her istek sunucuda yeniden denetlenir.

Kim Neyi İçe Aktarabilir

İçe aktarma yetkisi, paketin geldiği projeye göre değil, içe aktardığınız projeye göre sorulur. Sırasıyla iki kural işler:

• Hedef projede Proje Yönetimi → Export/Import yetkiniz varsa paketin tamamını içe aktarabilirsiniz.
• Yoksa paketteki her nesne tek tek denetlenir: her nesne için, o nesnenin kendi kategorisinde hedef projede Export/Import yetkisi gerekir. Yetkiniz olmayan tek bir nesne içe aktarmanın tamamını durdurur; denetim ilk kayıt yazılmadan önce çalıştığı için geriye yarım aktarılmış veri kalmaz.

Bu kural sihirbazda da, tek nesne (JSON) içe aktarımında da, APIops üzerinden yapılan aktarımda da aynı şekilde geçerlidir. Denetim paketin taşıdığı her nesneyi kapsar: bir API Proxy paketinin içindeki Consumer, sertifika ya da bağlantı da, proxy'ye gömülü DB/Script/Mock API tanımı da kendi kategorisine göre sorulur. Örneğin yalnızca API Yönetimi Export/Import yetkisi olan bir kullanıcı, içinde Consumer bulunan bir API Proxy paketini aktaramaz; Consumer için Kimlik kategorisinde de yetki gerekir.

Aynı kural eşleme adımındaki "paketten oluştur" seçeneği için de işler: orada oluşturulan nesne, sihirbazda seçtiğiniz ana tipe göre değil, oluşturulan nesnenin kendi kategorisine göre yetkilendirilir.

Paket okunamazsa — bozuk ZIP, geçersiz içerik ya da eksik parola — istek yetkilendirilemediği için reddedilir; okunamayan bir paket "yetki denetimi atlanmış" sayılmaz.

not

Önceki sürümlerde bu denetimin iki boşluğu vardı: nesne bazlı denetim yalnızca tek nesne içe aktarımında çalışıyor, ZIP paketi hedef proje denetimiyle kabul ediliyordu; sihirbazda ise paket okunamadığında denetim yalnızca ana nesne tipine düşüyor, paketteki diğer nesneler yetki sorulmadan yazılabiliyordu. İkisi de kapatıldı. Operatörleriniz yalnızca kategori düzeyinde yetkili oldukları projelere paket aktarıyorsa, bu yetkilerin kullandıkları paketlerdeki her nesne tipini — bağımlılıklar ve gömülü API Oluşturucu tanımları dâhil — kapsadığını doğrulayın; kapsamıyorsa daha önce tamamlanan bir aktarım artık yetki hatası verecektir.

Paket Boyutu

İçe aktarma, bir paketin ne kadar genişleyebileceğini sınırlar: en fazla 20.000 dosya, dosya başına en fazla 256 MB ve toplamda en fazla 1 GB. Gerçek export'lar bu sınırların çok altında kalır. Sınırlardan birini aşan paket açıklayıcı bir mesajla reddedilir; paketi daha küçük parçalar hâlinde export edin.

Mapping & Dependencies (Eşleştirme ve Bağımlılıklar)

Bağımlılık tespiti ve eşleştirme, sihirbazın en kritik parçasıdır — bir nesnenin taşınabilir olması, kullandığı her alt kaynağın hedefte doğru şekilde çözülmesine bağlıdır.

Politika Grubu Bağımlılığı Tespiti ve Eşleme

• Bir API Proxy, Proxy Group veya Politika Grubu dışa aktarıldığında içindeki her politika taranır; global olarak işaretli her politika (tekil ya da bir politika grubunun içindeki) ayrı bir bağımlılık olarak listelenir.
• Bir Politika Grubu'nun içindeki global politikalar, grubun kendisinden bağımsız olarak da ayrı birer bağımlılık olarak eklenir — böylece hedefte hem grup hem de içindeki global politikalar doğru şekilde oluşturulur veya eşlenir. Yerel (global olmayan) alt politikalar grupla birlikte gömülü taşınır.
• Her politika kendi içinde kullandığı sertifika, IP grubu ve kimlik bilgisini de ayrıca bağımlılık olarak yüzeye çıkarır (örn. bir JOSE politikasının kullandığı JWK, bir IP kural politikasının IP grubu).
• Bir Proxy Group dışa aktarıldığında üye API Proxy'lerin her biri, tek başına dışa aktarılmış gibi kendi tam bağımlılık ağacıyla çözülür.
• Aynı bağımlılık birden fazla seçili nesne tarafından kullanılıyorsa listede tek kopya olarak gösterilir, paylaşıldığı belirtilir ve pakete de tek kopya olarak yazılır.

Global Politika / Ortam Değişkeni / Kimlik Bilgisi Anahtarı Eşleme

• Bir Global Politika içe aktarımda hedefteki mevcut bir politikayla eşleştirilirse, onu kullanan tüm API Proxy, Proxy Group ve Politika Grubu kayıtlarındaki referans hedef politikaya yeniden yönlendirilir — böylece isim çakışmasından doğan bir kopya oluşmaz, aynı hedef politika kullanılmaya devam eder.
• Ortam değişkeni bağımlılıkları isme göre eşleştirilir: paketteki her ${DEĞİŞKEN_ADI} referansı, seçilen hedef değişkenin adına göre yeniden yazılır. Hedefte aynı isimde bir değişken yoksa pakette gelen tanımdan Global veya Ortam-özel bir değişken oluşturulabilir; ortam-özel oluşturmada kaynak ortam adları hedef ortamlarla eşleştirilir. Değişken değerleri pakete dahil edilmez, hedefte ayrıca girilmesi gerekir.
• Kimlik Bilgisi (Credential) bağımlılıkları kullanıcı adına göre eşleştirilir; parola/anahtar gibi secret bilgiler düz metin olarak taşınmaz — ya mevcut bir kimlik bilgisiyle eşlenir ya da hedefte yeniden girilir. Bir kimlik bilgisinin taşıdığı sertifika, key store veya trust store referansı hedefte çözülemezse bu referans artık sessizce bozuk bırakılmaz: referans temizlenir ve içe aktarma raporunda görünür bir uyarı üretilir — hedefte doğru sertifikayı yeniden seçmeniz gerekir.
• Sertifika / Key Store / Crypto Key / JWK bağımlılıkları eşlendiğinde, onu referans veren tüm dosyalardaki ilgili alanlar (bir kimlik bilgisinin özel anahtarı, bir JOSE politikasının kullandığı JWK, bir proxy'nin güvenli bağlantı sertifikaları vb.) hedefin kimliğine yeniden yazılır.
• Bir paketteki ortam kimliği kaynak kuruluma aittir; bu nedenle hedefte karşılığı bulunmayan bir sertifika ailesi kaydının ortam referansı içe aktarımda saklanmaz, düşürülür. Böyle bir referans yine de bir nesnenin üzerinde kaldığında, Sertifika, Key Store, Crypto Key ve JWK ekranları bunu ham bir kimlik yazmak yerine Bilinmeyen ortam uyarısıyla işaretler — bozuk atama görünür kalır ve aynı satırdan düzeltilebilir. Tek istisna API Manager'ın kendi apimanager ortamıdır: Ortamlar altında hiçbir zaman bir kayıt olarak bulunmayan bu sözde (pseudo) ortam her zaman geçerli sayılır ve kendi adıyla gösterilir.
• Veritabanı bağlantısı bağımlılıkları eşlendiğinde, API Creator'ın gömülü bağlantı referansı hedef bağlantıya yeniden yönlendirilir; bağlantı parolaları pakete dahil edilmez ve eşleştirme adayı olarak yalnızca aynı veritabanı tipindeki bağlantılar sunulur (örn. bir Oracle bağlantısı yalnızca başka bir Oracle bağlantısıyla eşleşebilir).

Dışlanan (Exclude Edilen) Bağımlılık Davranışı

• Birden fazla nesne içeren bir pakette (örn. birden fazla API Proxy ya da bir Proxy Group'un üye proxy'leri), istenmeyen bir nesne içe aktarımdan çıkarılabilir; yalnızca o nesneye özel bağımlılıklar da düşer — başka kalan bir nesne tarafından da kullanılan paylaşılan bağımlılıklar pakette kalmaya devam eder.
• Dışa aktarımda bir bağımlılığın işareti kaldırılırsa o bağımlılık pakete hiç dahil edilmez; bağımlılığı kullanan nesne hedefte söz konusu bağımlılık mevcut değilse kaynaktaki referansı olduğu gibi taşır ve bu referansın hedefte elle tamamlanması gerekir.
• Dışa aktarım öncesinde otomatik bir uyarı taraması yapılır: yakında süresi dolacak sertifikalar, gizli ortam değişkenleri, sertifika/bağlantı/kimlik bilgisi hatırlatmaları ve (içe aktarım tarafında) hedef projede eksik olan ortam değişkenleri bu taramada raporlanır.
• Bu taramadaki hatırlatmalar, parola verilmeden üretilen düz paketler içindir: pakete giren sertifika özel anahtarı gibi değerler düz pakette dosyayı eline geçiren herkes tarafından okunabilir. Pakete bir parola verirseniz bu değerler de paketle birlikte şifrelenir — ayrıntı için Paket Şifreleme bölümüne bakın.

Proje İçe Aktarımında Relative Path Kuralları

• Dışa aktarımda, kaynak projenin relative path öneki API Proxy/Proxy Group'un Client Route bilgisinden çıkarılır; pakette yalnızca proxy'ye özgü yol kısmı kalır — böylece paket kaynak projeye bağımlı olmaz.
• İçe aktarımda, hedef projenin kendi relative path öneki (etkinse) otomatik olarak öne eklenir; Client Route düzenleyicisinde bu önek sabit (değiştirilemez) şekilde gösterilir, yalnızca proxy'ye özgü kısım düzenlenebilir — böylece proxy yeni projede doğru yol altında, önek tekrarlanmadan devreye alınır.

AI Nesnesi Bağımlılığı Tespiti ve Eşleme

• Bir LLM Provider'ın bağımlılık adımı, bağlı olduğu sağlayıcı tanımını (Provider Definition) ve sağlayıcının kullandığı model katalogu kayıtlarını da yüzeye çıkarır — ama yalnızca bunlar projenizin oluşturduğu özel (custom) kayıtlarsa. Özel model katalogu kayıtları pakete dahil edilir ve içe aktarımda hedefte otomatik olarak oluşturulur. Apinizer'ın platformla birlikte gelen hazır (built-in) sağlayıcı tanımları ve hazır katalog modelleri hiçbir zaman pakete dahil edilmez — içe aktarımda sağlayıcının/modelin kendi tanımlayıcı koduna göre otomatik olarak çözülür, dolayısıyla bunlar için eşleştirme yapmanıza gerek kalmaz. LLM Provider'ın kendisi her zaman kendi secret'ını (API anahtarı/sırrı) taşır, bu yüzden her zaman secret bir bağımlılık olarak pakete girer.
• Bir Knowledge Base, üzerine kurulduğu Vector DB bağlantısını ve embedding için kullandığı LLM Provider'ı bağımlılık olarak yüzeye çıkarır. Pakete yalnızca knowledge base'in tanımı girer — içine önceden indekslenmiş dokümanlar pakete dahil edilmez, hedefte yeniden (indeksleyerek) eklenmesi gerekir.
• MCP/A2A Gateway'leri API Proxy (type=MCP / type=A2A) olarak export edilir ve çözülecek ayrı bir bağlantı bağımlılığı taşımaz: bir Passthrough proxy'nin arka uç sunucu(ları) ile bir Araç/Ajan Çağrısı politikasının gömülü sunucusu, proxy'nin kendisinin bir parçası olarak satır içi paketlenir.
• PII Preset ve Prompt Guard Preset başka hiçbir dışa aktarılabilir nesneye referans taşımaz — her ikisi de kendi içinde tamamlanmış bir örüntü (pattern) tanımıdır, bu yüzden ayrı bir bağımlılık adımı olmadan doğrudan dışa aktarılır. Model Definition ve Vector DB ise bağımlılık adımından geçer: özel bir model tanımı kullandığı özel bir sağlayıcı tanımına (Provider Definition) referans verebilir, bir Vector DB bağlantısının ayarları ortam değişkeni referansları içerebilir. Böyle bir referans yoksa adım "bağımlılık bulunamadı" boş-durum mesajını gösterip nesneyi doğrudan dışa aktarır.
• PII Preset ve Prompt Guard Preset — projenize özel olanlar dahil — yalnızca sistem yöneticisi tarafından oluşturulabilir veya düzenlenebilir. Sıradan bir projeden bakıldığında sihirbazın nesne listesinde yalnızca projenize daha önce tanımlanmış preset'ler görünür; platformun hazır (built-in) preset kataloğu burada listelenmez.

MCP Kaynak API Proxy'leri Bağımlılığı ve Eşleme

• Bir MCP Gateway başka bir API Proxy'nin uç noktalarını araç olarak yayımladığında (Araçları Aç modu), bu araçların arkasındaki her ayrı API Proxy kendi bağımlılığı olarak yüzeye çıkar ve MCP Kaynak API Proxy'leri etiketiyle listelenir — bu, yukarıda anlatılan satır içi sunucu tanımından (bir Passthrough proxy'nin arka ucu ya da bir Araç/Ajan Çağrısı politikasının gömülü sunucusu) FARKLIDIR; o hâlâ ağ geçidinin kendi paketinin bir parçası olarak satır içi kalmaya devam eder.
• İçe aktarımda her kaynak proxy referansı şu sırayla çözülür: (1) sihirbazın eşleme adımında verdiğiniz açık eşleme; (2) o yoksa hedef projede aynı ada ve aynı API tipine sahip tek bir API Proxy; (3) o da yoksa, dışa aktarımda dahil ettiyseniz pakette taşınan proxy kopyası — bu durumda proxy yeni bir nesne olarak içe aktarılır ve ardından araca bağlanır. Aynı kuruluma yeniden içe aktarılan bir paket, yukarıdakilerin hiçbiri geçerli değilse ek olarak proxy'nin özgün kimliğine (id) göre de çözülebilir.
• MCP Gateway'in kendisinde seçilen Replace Existing, bağlandığı kaynak proxy'yi hiçbir zaman değiştirmez: araç yukarıdaki 1. veya 2. adımla hedefte zaten var olan bir proxy'ye bağlanıyorsa, o proxy'nin içeriği olduğu gibi kalır — yalnızca ağ geçidinin kendi tanımı değiştirilir. Kaynak proxy, ancak aynı işlemde ayrıca bir ana nesne olarak da seçildiyse kendi Replace Existing / Import as New tercihini izler.
• İçe aktarma, hiçbir kayıt yazılmadan önce, üç durumda reddedilir: kaynak proxy ne eşlemeyle ne ad+tiple ne de pakette bulunabiliyorsa (mcpSourceProxyUnresolved); hedefte aynı ada ve aynı API tipine sahip birden fazla proxy varsa ve hangisine bağlanılacağı belirsizse (mcpSourceProxyAmbiguous); ya da bir araç, kaynak proxy'nin tek bir işlemine (HTTP metodu + yol) sabitlenmişse ve bu işlem içe aktarmanın bağlayacağı proxy'de yoksa (mcpToolEndpointMissing). Her mesaj ağ geçidini ve aracı adıyla belirtip sonraki adımı söyler — aracı eşleme adımında istediğiniz proxy'ye eşleyin, eksik uç noktayı orada tanımlayın ya da ağ geçidini kaynak proxy'lerini dahil ederek yeniden dışa aktarın.
• Bu bağımlılık hedefte Apinizer 2026.09.3 veya sonrasını gerektirir: bunu taşıyan bir paket, bundan daha eski bir kuruluma içe aktarılamaz.

Bir Uptime Takibi ya da Anomaly Detector kaydının bildirim konnektörü — uyarılarının çıktığı mail ya da webhook bağlantısı — diğer her bağlantı tabanlı referans gibi bir bağımlılık olarak pakete dahil edilir; yedek (failover) bağlantısı da, onun için failover etkinse, tıpkı bir SIEM hedefinin yedek konnektörü gibi (bkz. aşağıdaki SIEM Ayarları).

Kimlik ve Limit Yönetimi Tipleri

Limit Planı, API İstemcisi, Limit Ataması ve Erişim Yetkilendirmesi, sihirbazın Kimlik kategorisine eklenmiş dört tiptir. Hedefle eşleşmeleri iç kayıt kimliğine (id) göre değil, kalıcı bir ad ya da anahtara göre yapılır — bir yeniden adlandırma iki tarafı yanlış eşleştirmesin diye. Bu dördü diğer tiplerden ayıran ortak bir davranış da vardır: içe aktarma bunlardan hiçbirini kendiliğinden yürürlüğe koymaz.

İçe aktarma hiçbir şeyi otomatik olarak devreye almaz

• Limit Planı — Taslak plan ve taslak bir revizyonla gelir. Planı yayımlamak hedefte ayrı bir operatör işlemidir; bir atama bu planı ancak yayımlandıktan sonra kullanabilir.
• API İstemcisi — Taslak durumda ve secret bekleyen hâliyle gelir. Secret pakete hiçbir zaman girmez — hedefte yeni bir secret üretip istemciyi etkinleştirmeniz gerekir.
• Limit Ataması — Taslak atama olarak gelir; hedefte etkinleştirilmeden hiçbir trafiği etkilemez.
• Erişim Yetkilendirmesi — Taslak yetkilendirme olarak gelir; hedefte etkinleştirilmeden hiçbir erişim sağlamaz.

Limit Planı

• Bir limit planı, kural gövdesini oluşturan revizyonlarıyla birlikte tek bir dosya olarak taşınır. Kendi başına bir bağımlılığı yoktur — kuralları sayısal eşik ve pencere değerlerinden oluşur, başka bir nesneye referans vermez.
• Import as New ile oluşan plan her zaman Taslak durumunda doğar; pakette gelen kural gövdesi planın ilk taslak revizyonu olur. Planı yürürlüğe almak (yayımlamak) içe aktarmanın parçası değildir, ilgili ekrandan ayrıca yapılır.
• Replace Existing hedefteki planın adını, açıklamasını ve etiketlerini her durumda günceller ve pakette gelen kural gövdesini hedefte yeni bir taslak revizyon olarak eklemeye çalışır. Bu ekleme iki durumda uygulanmaz — hedefte zaten açık bir taslak revizyon varsa ya da hedef plan kullanımdan kaldırılmışsa (RETIRED) — her iki durumda da temel bilgi güncellemesi kalıcı kalır, yalnızca kural gövdesi atlanır ve içe aktarma özetinde bildirilir.
• Hedefle eşleştirme plan adına göre değil, planın kalıcı anahtarına (plan key) göre yapılır. Bu anahtar hedefte başka bir plan tarafından kullanılıyorsa Import as New reddedilir — sessizce başka bir anahtar üretilmez; bu durumda Replace Existing kullanılmalıdır.

API İstemcisi

• Bir tüketiciye veya bir uygulamaya ait tipli OAuth istemcisi taşınabilir. İstemcinin kendine ait bir yönetim ekranı yoktur; sahibinin (kimlik bilgisi ya da uygulama) detay ekranından yönetilir.
• İstemcinin gizli materyali (client secret) pakete hiçbir zaman girmez. İçe aktarılan istemci her zaman Taslak durumunda ve secret bekleyen hâliyle oluşturulur; ilk secret'ın hedefte ayrıca üretilmesi ve istemcinin etkinleştirilmesi gerekir.
• Replace Existing yalnızca istemcinin temel bilgilerini ve ihraç ayarlarını günceller; hedefteki secret bilgisi, kullanım durumu, askıya alma/iptal bilgisi ve sayaçları olduğu gibi kalır. Pakette gelen sahip hedefteki istemcinin mevcut sahibinden farklıysa bu işlem reddedilir — bir istemci başka bir sahibe taşınamaz.
• İstemci tanımlayıcısı (client identifier) kurulum genelinde, tüm projeler boyunca benzersizdir. Pakette gelen tanımlayıcı hedefte başka bir istemci tarafından kullanılıyorsa — başka bir projede olsa bile — içe aktarma reddedilir; sessizce yeni bir tanımlayıcı üretilmez.
• İstemcinin sahibi (tüketici kimlik bilgisi ya da uygulama) hedefte bulunamazsa, ya da sahip adı hedefte birden fazla uygulamayla eşleşiyorsa, dosya için içe aktarma reddedilir — istemci sahipsiz ya da belirsiz sahiple oluşturulmaz. Sahibi bir tüketiciyse ilgili kimlik bilgisi pakete bağımlılık olarak dahil edilebilir; sahibi bir uygulamaysa uygulamanın hedefte aynı adla önceden var olması gerekir — uygulamalar sihirbazla taşınan bir nesne tipi değildir.

Limit Ataması

• Bir özneye (tüketici, API istemcisi, uygulama, organizasyon, proje veya kural tabanlı bir grup) tanımlanmış limit ataması taşınabilir.
• İçe aktarma hiçbir tavanı yürürlüğe koymaz: yeni bir atama her zaman Taslak durumunda oluşur ve hiçbir Gateway'e iletilmez.
• Replace Existing yalnızca hedefteki atama hâlâ Taslak durumundaysa içeriğini günceller; hedefteki atama etkinleştirilmiş ya da sona ermişse dokunulmaz ve bu durum içe aktarma özetinde ayrıca bildirilir.
• Bağımlılıkları: atamanın adlandırdığı plan(lar) pakete dahil edilebilir; öznesi bir tüketiciyse ilgili kimlik bilgisi, öznesi bir API İstemcisiyse ilgili istemci de pakete dahil edilebilir. Hedefi bir proxy veya proxy grubuysa bu yalnızca bir referanstır — hedef nesnenin kendisi pakete girmez, hedefte aynı adla önceden var olması gerekir. Ortam ise adıyla taşınır ve hedefte yalnızca doğrulanır, çevrilmez.
• Özne, hedef, ortam veya adlandırılan plan hedefte çözülemezse o dosya için içe aktarma reddedilir; referans sessizce düşürülmez.
• Kurulum genelini kapsayan (PLATFORM öznesi — hiçbir projeye ait olmayan tavan) bir atama sihirbazın nesne listesinde hiç görünmez ve bu sihirbazla içe aktarılamaz.

Erişim Yetkilendirmesi

• Bir tüketici veya uygulamanın bir proxy, proxy grubu, API ürünü ya da tek bir ortama daraltılmış proxy'ye erişimini tanımlayan kayıt taşınabilir.
• İçe aktarma hiçbir erişim vermez: yeni bir yetkilendirme her zaman Taslak durumunda oluşur ve etkinleştirilmeden hiçbir Gateway davranışını etkilemez.
• Replace Existing yalnızca hedefteki kayıt hâlâ Taslak durumundaysa hedefini ve geçerlilik penceresini günceller; etkinleştirilmiş ya da sonlandırılmış bir kayıt değiştirilmez.
• Pakette gelen özne hedefteki kayıttan farklıysa dosya reddedilir — bir yetkilendirme başka bir özneye devredilemez.
• Bağımlılığı yalnızca özne bir tüketiciyse vardır (ilgili kimlik bilgisi pakete dahil edilebilir); özne bir uygulamaysa ya da hedef bir API ürünüyse bunlar taşınmaz, hedefte aynı adla önceden var olması gerekir. Proxy, proxy grubu veya ortam hedefi de yalnızca bir referanstır, pakete girmez — adıyla eşleştirilir.
• Özne veya hedef (ortam dahil) hedefte çözülemezse o dosya için içe aktarma reddedilir; sessiz atlama yoktur.

API Ürünü Abonelik Planları

Bir API Ürününün abonelik planları, ürünün kendi paketinin içinde taşınır — ayrıca seçilen bir nesne tipi değildir. İçe aktarmada her plan, aktarılan ürüne yeniden bağlanır ve tıpkı plan ekranından kaydedilmiş bir plan gibi ele alınır: gateway'in uyguladığı limit profili anında oluşturulur, böylece aktarılan plan var olduğu andan itibaren hız limitini ve kotasını uygular. Ardından "planı açıp bir kez kaydet" gibi bir adım gerekmez ve hiçbir plan, hiçbir şeyin uygulamadığı bir limit göstererek gelmez.

• Import as New, her plana bu kurulumda yeni üretilmiş kendi profilini verir. Planın kaynak kurulumda gösterdiği profil taşınmaz — profiller, onları uygulayan kuruluma aittir.
• Replace Existing, ikinci bir profil açmak yerine hedef planın kendi profilini yerinde günceller; böylece o profile bağlı tüm abonelikler aynı profili çözmeye devam eder ve yalnızca yeni sayıları görür.
• Bir Replace, planın hız limitini, kotasını, aralığını ya da aşım davranışını değiştirdiğinde, planın onaylanmış abonelikleri arka planda yeniden senkronlanır; böylece gateway, paketin değiştirdiği eski limiti uygulamayı bırakır.
• Hız limiti ya da kotası hiçbir çağrıya izin vermeyen (0 ya da negatif) bir plan içe aktarılmaz: o plan için hiçbir şey yazılmadan atlanır ve gerekçesi, içe aktarma raporundaki düşen referanslar arasında görünür. Paketin geri kalanı normal şekilde aktarılır — kullanılamaz tek bir plan diğer her şeyi iptal etmez. İlgili planı kaynak kurulumda düzeltip yeniden dışa aktarın.

Bütün bir portalın kopyalanmasında (Portal Ayarları → Clone/Transfer) aynı kural bir farkla geçerlidir: portal paketindeki uygulamalar ve abonelikler planlara referans verdiği için, kullanılamaz bir plan atlanmaz — ilk kayıt yazılmadan tüm kopyalama reddedilir. Hiçbir kayıt oluşturulmaz ve mesaj, düzeltilmesi gereken planı adıyla söyler.

SIEM Ayarları

SIEM Ayarları, sihirbazın tek Admin tipidir: kataloğun geri kalanından farklı olarak hiçbir projeye ait değildir — kurulum başına yalnızca bir tane vardır — ve onu yalnızca sistem yöneticisi dışa ya da içe aktarabilir, ister sihirbazdan ister APIops üzerinden. Sahibi bir proje olmadığı için hiçbir projenin kendi Dışa/İçe Aktar menüsünde görünmez; yalnızca Administration → Dışa/İçe Aktar grubundan erişilir.

• Pakete giren: SIEM ve Log Yönlendirme yapılandırmasının tamamı tek dosya olarak dışa aktarılır — her hedef (bağlantı referansı, yük profili, boyut politikası, gizlilik profili ve hat kuralları dahil) ve iki yerel saklama anahtarı. Bir hedefin bağlantısı — ve varsa yedek (failover) bağlantısı — diğer her bağlantı tabanlı tipte olduğu gibi bir bağımlılık olarak taşınır: pakete dahil edin, ya da içe aktarımda hedefte mevcut bir bağlantı yapılandırmasıyla adına göre eşleşsin.
• Pakete girmeyen: bir hattın yetkisi (LEGACY ya da ACTIVE) hiçbir zaman pakete girmez ve içe aktarımla değişmez — bir hattı yalnızca hedefteki SIEM ve Log Yönlendirme sayfasının kendisi, hedefin üzerinde, devreye alabilir. Kaydın sunucu yönetimli alanları (revizyon sayacı, son değişiklik bilgisi) de aynı şekilde hiçbir zaman taşınmaz; hedef kendi değerlerini korur.
• Replace Existing, hedefteki hedef listesini pakettekiyle tümüyle değiştirir ve iki yerel saklama anahtarını da paketten alır; hedefin kendi hat yetkisi olduğu gibi kalır.
• Import as New, paketteki hedefleri hedefin mevcut listesine ekler — orada zaten kullanılan bir ad -imported soneki alır — ve hedefin kendi yerel saklama anahtarlarına ile hat yetkisine dokunmaz.
• Bağlantısı hedefte çözülemeyen bir hedef — pakete dahil edilmemiş ve hedefte aynı ad/tipte bir bağlantı da yoksa — yine de içe aktarılır, yalnızca Enabled anahtarı kapalı olarak; içe aktarma sonucu hedefin adını ve bulunamayan bağlantıyı adlandırır. Bozuk bir referansla asla etkin içe aktarılmaz, asla sessizce düşürülmez. Aynı kural yedek bağlantı için de geçerlidir.
• Import as New ile oluşan ve API Güvenliği hattını gönderen, kendi gizlilik profili olmayan bir hedef, bu sayfadan doğrudan oluşturulan bir hedefle aynı maskeleme kurallarıyla gelir — bkz. Gizlilik Profili.
• Gizlilik tuzu pakette aynen, düz metin olarak taşınır — bugün başka paketlerdeki bir bağlantının tuzunun taşındığı gibi. Bu bilinçlidir: iki kurulum aynı tuzu paylaşmadan aynı değeri aynı özete indirmez. Paket paylaşılan bir yerde duracaksa — örneğin bir CI deposunda — parolalı dışa aktarın (bkz. yukarıdaki Paket Şifreleme); şifrelenmemiş bir paket bu tuzu ve onunla hesaplanmış her şeyi, dosyayı elinde bulunduran herkese okunur bırakır.

Transfer API v2 (APIops)

CI/CD hattı için aynı dışa/içe aktarma motoru, sürümlenmiş bir Management API yüzeyi olarak da sunulur: Transfer API v2. Bu yüzey ne bu sihirbazın ne de düz APIops dışa/içe aktarma çağrılarının vermediği tek bir garantiyi ekler — pipeline'ın incelediği şeyle uygulanan şeyin, ikisi arasında hiçbir şey değişmemiş olarak, birebir aynı olması.

Akış, önizle-sonra-uygula biçiminde dört çağrıdan oluşur: bir preview (önizleme) dışa aktarma seçimini (ve bağımlılıklarını) çözer ve bir digest döner; export run aynı isteği bu digest ile tekrarlar ve seçim artık farklı çözümlenecekse reddedilir. İçe aktarma tarafında bir preflight yüklenen paketi hedef projeye karşı analiz eder ve kendi digest'ini döner; import run paketi bu digest ile tekrarlar — hedef proje o zamandan beri değiştiyse reddedilir — ve tekrarlanan bir pipeline adımının aynı içe aktarmayı iki kez uygulayamaması için bir Idempotency-Key başlığı zorunlu kılar.

Bu ek bir yüzeydir: mevcut /export-import/{type}/export|import uçları, sapma kontrolüne ihtiyaç duymayan pipeline'lar için aynen çalışmaya devam eder. Tam istek/yanıt şemaları, hata anahtarları ve uçtan uca bir curl örneği için bkz. Transfer API v2 (İngilizce, API Referansı).

Kullanım Senaryoları

Ortamlar Arası Transfer

Erişim kısıtlamasından dolayı fiziksel olarak, production ve test adlı iki farklı ortamda kurulu iki tane Apinizer uygulaması olduğunu varsayalım. Production ortamı istemcilere, test ortamı ise yazılım geliştiricilere hizmet etmektedir. Test ortamındaki API Proxy ve uygulanan politikalar ve konfigürasyonlar, production ortamına da uygulanması istenmektedir. Bu durumda test ortamındaki API Proxy, bağımlılıklarıyla birlikte dışa aktarılır. Sonrasında oluşturulan paket, sihirbaz ile production ortamına içe aktarılır ve bağımlılıklar hedefteki karşılıklarıyla eşleştirilir.

Konfigürasyon İzleme

Konfigürasyon değişiklikleri izlenebilir. Kurum, güvenlik kuralları nedeniyle politika ayarlarındaki farklılıkları izlemek isteyebilir. Bunun için CI sürecine, dışa aktarılan politika, API Proxy ya da projeye ait konfigürasyon dosyası eklenmelidir.

İlgili Sayfalar

• Ortamlar arası otomatik değişken eşleştirme ve onay mekanizmalarıyla API taşıma ihtiyacınız varsa API Promotion sayfasına göz atın — bağımlılık tespiti mantığı burada anlatılan sihirbazla örtüşür, ancak API Promotion aynı kurulum içindeki ortamlar arasında onay akışlı bir taşıma sunar.
• Denetim Kayıtları — "İçeriğin farklı olduğunu anladım" onayıyla yapılan içe aktarmaları kimin onayladığını buradan görebilirsiniz.
• Ortam Değişkenleri
• Proxy Group
• LLM Sağlayıcıları ve Bağlantılar
• Model Kataloğu ve Fiyatlandırma
• Bilgi Tabanları
• Vektör Veritabanı
• MCP Gateway
• A2A Gateway
• SIEM ve Log Yönlendirme
• Bağlantı Yönetimi

İlgili İşlemler

• API Proxy Dışa Aktar
• API Proxy İçe Aktar
• Anahtar Dışa Aktar
• Key Store Dışa Aktar
• Global Politikalar
• Transfer API v2 - Aynı motor üzerine kurulu, sürümlenmiş, önizle-sonra-uygula CI/CD yüzeyi