DEV Community: Tobias Hoffmann

En İyi 2026 Solana API'leri: Geliştiriciler, Cüzdan Uygulamaları ve Yapay Zeka Ajanları

Tobias Hoffmann — Fri, 05 Jun 2026 14:19:20 +0000

Solana, yüksek performanslı blockchain uygulamaları için en önemli ekosistemlerden biri haline geldi.

Hızı, düşük işlem maliyetleri ve büyüyen geliştirici ekosistemi; cüzdan uygulamaları, DeFi platformları, ticaret sistemleri ve zincir üstü verilerle doğrudan çalışan yapay zeka destekli ajanlar için Solana'yı güçlü bir seçenek haline getiriyor.

Ancak Solana üzerinde anlamlı bir ürün geliştirmek artık yalnızca akıllı sözleşme yazmakla sınırlı değil.

Modern Solana uygulamalarında genellikle şu altyapı katmanlarına ihtiyaç duyulur:

cüzdan bakiyeleri ve portföy takibi
işlem geçmişi ve indeksleme
token fiyatlandırması ve likidite verileri
takas yönlendirme ve DeFi etkileşimleri
gerçek zamanlı blockchain olayları
yapay zeka tarafından okunabilir yapılandırılmış veriler

Bu nedenle Solana API'leri uygulama mimarisinin kritik bir parçası haline gelir.

Buradaki zorluk şu: "Solana API" artık tek bir kategori değil. Farklı sağlayıcılar; ham RPC altyapısından DeFi yönlendirmesine, cüzdan zekasından piyasa verilerine kadar yığının farklı katmanlarını çözüyor.

Bu kılavuzda, geliştiriciler, cüzdan uygulamaları ve yapay zeka ajanları için 2026'da öne çıkan Solana API'lerini uygulama odaklı olarak ele alıyoruz:

CoinStats Solana API
Chainstack
Jupiter
Shyft
Birdeye
Solscan

Amaç yalnızca popüler araçları listelemek değil; her API'nin pratikte hangi problemi çözdüğünü ve gerçek bir Solana mimarisinde nereye yerleştiğini göstermektir.

İyi Bir Solana API'sini Ne Yapar?

Bir sağlayıcı seçmeden önce, uygulamanızın hangi veri katmanlarına ihtiyaç duyduğunu netleştirin.

1. Cüzdan ve Hesap Verileri

Çoğu Solana uygulaması cüzdan görünürlüğü ile başlar.

Tipik ihtiyaçlar:

token bakiyeleri
NFT varlıkları
hesap durumu
stake pozisyonları

Bu katman olmadan cüzdanlar, portföy panelleri veya yapay zeka destekli kripto asistanları oluşturmak zordur.

Örnek kullanım akışı:

// Pseudo-code: cüzdan verisini uygulama katmanına çekme
const walletAddress = "USER_SOLANA_WALLET";

const balances = await api.getWalletBalances(walletAddress);
const transactions = await api.getWalletTransactions(walletAddress);

return {
  wallet: walletAddress,
  balances,
  transactions,
};

2. İşlem Geçmişi ve İndeksleme

Ham blockchain verileriyle doğrudan çalışmak genellikle karmaşıktır.

İyi bir API şu çıktıları sağlamalıdır:

yapılandırılmış işlem geçmişi
ayrıştırılmış talimatlar
olay düzeyinde indeksleme
filtrelenebilir sorgular

Bu özellikle analitik araçları, hata ayıklama panelleri ve yapay zeka ajanları için önemlidir.

Örnek kontrol listesi:

[ ] İşlemler zaman sırasına göre alınabiliyor mu?
[ ] Token transferleri ayrıştırılmış mı?
[ ] Başarısız işlemler görülebiliyor mu?
[ ] Program / hesap bazlı filtreleme var mı?
[ ] Yanıt formatı yapay zeka ajanları için okunabilir mi?

3. DeFi ve Takas Altyapısı

Solana'nın DeFi ekosistemi hızlı değişir. Bu nedenle uygulamalar genellikle ayrı ayrı DEX entegrasyonları yerine toplama ve yönlendirme katmanlarına ihtiyaç duyar.

Yaygın gereksinimler:

takas yönlendirme
likidite verileri
DEX toplama
havuzlar arası fiyatlandırma

Örnek DeFi akışı:

Kullanıcı SOL -> USDC takası ister
        ↓
Uygulama rota ve fiyat bilgisi alır
        ↓
En iyi likidite kaynağı seçilir
        ↓
İşlem kullanıcı cüzdanı ile imzalanır
        ↓
Solana ağına gönderilir

4. Gerçek Zamanlı Performans

Solana uygulamaları gecikmeye karşı hassastır. Özellikle cüzdanlar, trading botları ve zincir üstü ajanlar için API performansı doğrudan kullanıcı deneyimini etkiler.

Kontrol edilmesi gerekenler:

hızlı RPC yanıtları
WebSocket veya streaming desteği
düşük gecikmeli indeksleme
üretim ortamında kararlı çalışma süresi

5. Yapay Zeka ve Otomasyon Hazırlığı

Yapay zeka ajanları için API'nin yalnızca veri döndürmesi yeterli değildir. Yanıtların bağlamlı, tutarlı ve makine tarafından kolay işlenebilir olması gerekir.

İdeal özellikler:

yapılandırılmış JSON çıktıları
ajan dostu uç noktalar
cüzdan, portföy ve işlem bağlamı
zincirler arası okunabilir veri modeli

1. CoinStats Solana API

CoinStats Solana API, cüzdan zekası, portföy takibi ve çok zincirli kripto verilerini tek bir yapılandırılmış sistemde birleştirmeye odaklanır.

Geliştiricileri bakiyeler, işlemler ve portföy analizi için ayrı API'leri birleştirmeye zorlamak yerine, CoinStats verileri cüzdanlar ve kullanıcı etkinliği etrafında düzenleyen birleşik bir katman sağlar.

Pratikte şu uygulamalarda kullanılır:

tokenlar arası cüzdan bakiyeleri
hesaplar arası işlem geçmişi
portföy düzeyinde performans takibi
DeFi maruziyeti ve varlık dağıtımı
çok zincirli portföy toplama

Bu yaklaşım özellikle bağlamın ham veriden daha önemli olduğu yapay zeka güdümlü uygulamalar için kullanışlıdır.

Örneğin, yalnızca token bakiyesi göstermek yerine uygulamanız şu tür içgörüler üretebilir:

portföy bileşimi
gerçekleşen ve gerçekleşmeyen performans
çapraz zincir varlık dağıtımı
geçmiş cüzdan davranışı

Bu, geliştiricilerin manuel olarak inşa etmesi gereken arka uç altyapısını azaltır.

Tipik kullanım alanları:

piyasa verileri
yapay zeka portföy asistanları
cüzdan takip uygulamaları
otomatik kripto gösterge tabloları
çok zincirli analitik araçlar

Örnek uygulama akışı:

// Pseudo-code: portföy odaklı cüzdan görünümü
const wallet = "USER_WALLET_ADDRESS";

const portfolio = await coinstats.getPortfolio(wallet);
const walletActivity = await coinstats.getWalletActivity(wallet);

const summary = {
  totalValue: portfolio.totalValue,
  assets: portfolio.assets,
  recentActivity: walletActivity.slice(0, 10),
};

console.log(summary);

CoinStats API düşük seviyeli blockchain erişiminden çok, ham zincir üstü verileri kullanılabilir finansal bağlama dönüştürmeye odaklanır. Uç nokta ayrıntıları ve kullanım örnekleri için bu Solana API kılavuzu daha fazla detay sunar.

Güçlü Yönler

Tek bir API'de birleşik cüzdan, portföy ve piyasa verileri
Solana dahil 120'den fazla zincir desteği
Güçlü portföy analitik katmanı
Yapay zeka ajanları için uygun veri modeli
Birden fazla veri sağlayıcısına olan ihtiyacı azaltır

En İyisi

Piyasa veri akışları, cüzdan uygulamaları, portföy analizi, yapay zeka portföy sistemleri, yapay zeka ticaret botları ve çok zincirli analitik platformları.

2. Chainstack

Chainstack, Solana uygulamaları için yönetilen blockchain düğümleri ve RPC hizmetleri sunar.

Bu listedeki birçok araçtan daha alt seviyede konumlanır. Odak noktası paketlenmiş DeFi veya analitik verileri değil; bağlantı, düğüm erişimi ve güvenilirliktir.

Geliştiriciler Chainstack'i kendi düğümlerini çalıştırmadan doğrudan Solana ile etkileşim kurmak için kullanır.

Yaygın kullanım alanları:

işlemleri gönderme ve okuma
zincir üstü durumu sorgulama
akıllı sözleşmelerle etkileşim
işlem akışlarını ve blok etkinliğini izleme
arka uç blockchain servislerini güçlendirme

RPC güvenilirliği özellikle üretim uygulamalarında kritiktir. Düğüm yanıt süreleri yavaş veya dengesizse, üzerine inşa edilen cüzdanlar, trading sistemleri ve yapay zeka ajanları da bundan etkilenir.

Örnek RPC kullanım akışı:

// Pseudo-code: Solana RPC üzerinden hesap bilgisi alma
const rpcUrl = process.env.SOLANA_RPC_URL;

const response = await fetch(rpcUrl, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    jsonrpc: "2.0",
    id: 1,
    method: "getAccountInfo",
    params: ["ACCOUNT_PUBLIC_KEY"],
  }),
});

const data = await response.json();
console.log(data);

Chainstack bir veri analizi platformu değildir. Temel bir altyapı sağlayıcısıdır.

Güçlü Yönler

Solana'nın ötesinde 70'ten fazla zincir desteği
Düşük gecikme için özel düğümler ve Yellowstone gRPC akışı
Altyapı yükü olmadan esnek ölçeklendirme
Yapay zeka ajanları ve LLM'ler için MCP sunucusu
Üretim düzeyinde çalışma süresi ve performans

En İyisi

Arka uç altyapısı, RPC erişimi ve yüksek performanslı Solana uygulamaları. DeFi uygulamaları, zincir üstü botlar ve temelinde güvenilir RPC'ye ihtiyaç duyan yapay zeka ajanları için uygundur.

3. Jupiter

Jupiter, Solana ekosistemindeki en önemli likidite toplama protokollerinden biridir.

Geleneksel bir veri API'si gibi davranmak yerine, merkeziyetsiz borsalar arasında takas yönlendirmeye odaklanır.

Bir kullanıcı token takası yapmak istediğinde, Jupiter mevcut likidite kaynakları arasında en verimli rotayı bulmaya yardımcı olur.

Geliştiriciler Jupiter'i şu tür ürünlerde entegre eder:

takas arayüzleri
ticaret botları
DeFi uygulamaları
otomatik portföy dengeleyiciler

Temel değeri, Solana DEX'leri arasındaki parçalanmış likiditeyi sadeleştirmesidir.

Her DEX'i ayrı ayrı entegre etmek yerine, Jupiter birleşik bir yönlendirme katmanı olarak kullanılabilir.

Örnek uygulama akışı:

1. Kullanıcı giriş tokenını seçer
2. Kullanıcı çıkış tokenını seçer
3. Uygulama Jupiter'den rota / fiyat bilgisi alır
4. Kullanıcı işlemi cüzdanında onaylar
5. İşlem Solana ağına gönderilir

Yapay zeka ajanları için Jupiter özellikle şu senaryolarda kullanışlıdır:

otomatik ticaret yürütme
optimize edilmiş takas kararları
çapraz DEX likidite erişimi

Jupiter daha çok veri erişiminden ziyade yürütme zekasıyla ilgilidir.

Güçlü Yönler

Güçlü takas yönlendirme
Solana likiditesini toplar
DeFi entegrasyonunu basitleştirir
Otomasyon sistemleri için uygundur

En İyisi

DeFi uygulamaları, ticaret botları ve otomatik yürütme sistemleri.

4. Shyft

Shyft, Solana uygulamaları için kimlik, uyumluluk ve yapılandırılmış blockchain veri hizmetleri sunar.

Odak noktası, blockchain verilerini daha okunabilir ve kurumsal kullanıma daha uygun hale getirmektir.

Ham işlem günlükleri yerine Shyft şu tür veriler sağlar:

ayrıştırılmış işlem verileri
kimlikle bağlantılı cüzdan bilgileri
yapılandırılmış olay takibi
uyumluluk odaklı blockchain içgörüleri

Bu, ham blockchain karmaşıklığı üzerinde netlik isteyen uygulamalar için kullanışlıdır.

Yaygın kullanım alanları:

fintech uygulamaları
uyumluluk gösterge tabloları
analitik platformları
kurumsal blockchain araçları

Yapay zeka sistemleri için yapılandırılmış veri özellikle değerlidir. Çünkü belirsizliği azaltır ve modelin daha doğru bağlam üretmesine yardımcı olur.

Örnek veri işleme yaklaşımı:

// Pseudo-code: ayrıştırılmış işlem verisini uygulama modeline dönüştürme
const parsedTransactions = await shyft.getParsedTransactions(wallet);

const normalized = parsedTransactions.map((tx) => ({
  signature: tx.signature,
  timestamp: tx.timestamp,
  type: tx.type,
  status: tx.status,
}));

console.log(normalized);

Shyft, ham blockchain verisi ile kullanılabilir uygulama düzeyinde zeka arasındaki boşluğu kapatmaya yardımcı olur.

Güçlü Yönler

Yapılandırılmış ve ayrıştırılmış blockchain verileri
Kimlik ve uyumluluk özellikleri
Kurumsal uygulamalar için kullanışlı
Yapay zeka dostu veri biçimlendirme

En İyisi

Uyumluluk araçları, yapılandırılmış analiz ve kurumsal Solana uygulamaları.

5. Birdeye

Birdeye, Solana odaklı bir piyasa verisi ve analitik platformudur.

Solana ekosistemi genelinde token performansı, likidite ve ticaret etkinliği hakkında ayrıntılı bilgiler sağlar.

Geliştiriciler Birdeye'ı şu amaçlarla kullanır:

token fiyat takibi
likidite analizi
DEX ticaret verileri
gerçek zamanlı piyasa akışları

Özellikle hızlı ve ayrıntılı Solana'ya özgü piyasa zekasına ihtiyaç duyan gösterge tabloları ve ticaret araçları için kullanışlıdır.

Genel kripto API'lerinin aksine, Birdeye Solana'ya özgü piyasa davranışına odaklanır.

Yapay zeka sistemleri için bu veriler şu alanlarda kullanılabilir:

sinyal üretimi
ticaret stratejisi analizi
piyasa izleme

Örnek kullanım modeli:

Token fiyatı alınır
        ↓
Likidite ve hacim kontrol edilir
        ↓
Anormal hareketler filtrelenir
        ↓
Dashboard veya bot karar katmanına gönderilir

Güçlü Yönler

Güçlü Solana piyasa odağı
Gerçek zamanlı DEX verileri
Token düzeyinde analiz
Ticaret gösterge tabloları için uygun

En İyisi

Piyasa gösterge tabloları, ticaret analizi ve Solana token takibi.

6. Solscan

Solscan, en yaygın kullanılan Solana blockchain gezginlerinden ve veri API'lerinden biridir.

Şunlara doğrudan erişim sağlar:

işlem geçmişi
cüzdan etkinliği
token meta verileri
blok düzeyinde bilgiler

Hem görsel bir gezgin hem de geliştirici API'si olarak kullanılabilir.

Geliştiriciler Solscan'ı genellikle şu ihtiyaçlar için kullanır:

ham blockchain şeffaflığı
cüzdan düzeyinde inceleme
işlem doğrulama
hata ayıklama ve analiz araçları

Daha yüksek seviyeli API'lerden farklı olarak Solscan, ham zincir verilerine daha yakındır.

Bu nedenle şu sistemler için kullanışlıdır:

adli blockchain analizi
hata ayıklama araçları
gezgin tabanlı uygulamalar

Örnek hata ayıklama akışı:

1. İşlem imzası alınır
2. Solscan üzerinde doğrulanır
3. Başarılı / başarısız durumu kontrol edilir
4. Program logları ve token transferleri incelenir
5. Uygulama tarafındaki hata nedeni izole edilir

Güçlü Yönler

Şeffaf blockchain veri erişimi
Güçlü gezgin altyapısı
Hata ayıklama ve analiz için kullanışlı
Geniş çapta benimsenmiş araç ekosistemi

En İyisi

Blockchain gezginleri, hata ayıklama araçları ve ham Solana veri erişimi.

Karşılaştırma Tablosu

API	Ana Odak	Kullanım Katmanı	En Uygun Senaryo
CoinStats Solana API	Cüzdan, portföy ve piyasa bağlamı	Uygulama / analiz katmanı	Cüzdan uygulamaları, AI portföy asistanları, çok zincirli paneller
Chainstack	RPC ve düğüm altyapısı	Altyapı katmanı	Üretim Solana uygulamaları, botlar, backend servisleri
Jupiter	Takas yönlendirme ve likidite toplama	DeFi yürütme katmanı	Swap arayüzleri, trading botları, otomatik dengeleme
Shyft	Yapılandırılmış blockchain verisi ve uyumluluk	Veri zenginleştirme katmanı	Kurumsal uygulamalar, uyumluluk panelleri, analitik
Birdeye	Solana piyasa verisi	Piyasa analizi katmanı	Token izleme, DEX analizi, trading dashboard'ları
Solscan	Blockchain gezgini ve ham veri	İnceleme / hata ayıklama katmanı	İşlem doğrulama, explorer uygulamaları, zincir üstü analiz

Hangi Solana API'sini Seçmelisiniz?

Seçimi uygulamanızın temel ihtiyacına göre yapın:

Yapılandırılmış finansal bağlama ihtiyaç duyan cüzdan uygulamaları, portföy gösterge tabloları veya yapay zeka portföy sistemleri geliştiriyorsanız CoinStats API'yi seçin.
Güvenilir Solana RPC altyapısına ihtiyacınız varsa Chainstack'i seçin.
Uygulamanız takaslara ve DeFi yürütmesine bağlıysa Jupiter'i seçin.
Yapılandırılmış veya uyumluluk dostu blockchain verilerine ihtiyacınız varsa Shyft'i seçin.
Solana'ya özgü piyasa analizleri istiyorsanız Birdeye'ı seçin.
Ham blockchain şeffaflığına ve hata ayıklama araçlarına ihtiyacınız varsa Solscan'ı seçin.

Pratik mimari örneği:

Frontend
  ├─ Cüzdan görünümü → CoinStats
  ├─ Swap ekranı → Jupiter
  ├─ Token fiyatları → Birdeye
  └─ İşlem detayları → Solscan

Backend
  ├─ RPC erişimi → Chainstack
  ├─ Yapılandırılmış işlem verisi → Shyft
  └─ AI ajan bağlamı → CoinStats + piyasa/veri API'leri

Son Düşünceler

Solana ekosistemi hızla genişlemeye devam ediyor ve modern kripto uygulamalarının gereksinimleri de aynı hızla artıyor.

Birçok proje artık basit blockchain erişiminden daha fazlasına ihtiyaç duyuyor. Cüzdan zekası, işlem izleme, portföy analizi, piyasa verileri ve DeFi görünürlüğünün aynı ürün deneyimi içinde birlikte çalışması gerekiyor.

Chainstack, Jupiter, Shyft, Birdeye ve Solscan Solana altyapı yığınının farklı bölümlerini çözerken, CoinStats API cüzdan takibi, portföy analizi, piyasa zekası ve çok zincirli görünürlüğü tek bir platformda birleştiren daha geniş bir yaklaşım sunar.

Geliştirici açısından en doğru seçim şuna bağlıdır:

Altyapı mı kuruyorsunuz? → Chainstack
Swap / DeFi yürütmesi mi gerekiyor? → Jupiter
Yapılandırılmış zincir verisi mi lazım? → Shyft
Piyasa analizi mi yapıyorsunuz? → Birdeye
Ham işlem incelemesi mi gerekiyor? → Solscan
Cüzdan + portföy + çok zincirli bağlam mı istiyorsunuz? → CoinStats

Sonuç olarak, en iyi Solana API'si uygulamanızın altyapı, ticaret, analiz, cüzdan zekası veya yapay zeka destekli kripto deneyimleri etrafında mı konumlandığına bağlıdır.

Rol Tabanlı Erişim Kontrolü (RBAC) ile API İşbirliğini Güvenli Hale Getirme

Tobias Hoffmann — Fri, 05 Jun 2026 10:54:07 +0000

TL;DR: Rol Tabanlı Erişim Kontrolü (RBAC), izinleri bireysel kullanıcılara değil rollere atayan bir güvenlik modelidir. API ekipleri için RBAC; erişimi ölçeklenebilir, denetlenebilir ve yönetilebilir hale getirir. API işbirliği için iyi bir RBAC yapısı Kuruluş → Ekip → Proje seviyelerinde izin hiyerarşisi, özel rol desteği ve SSO/SCIM gibi kurumsal entegrasyonlar sunmalıdır. Apidog, üç seviyede 12 yerleşik rol ve kurumsal ekipler için özel proje rolleriyle API varlıklarınızı kimlerin görüntüleyebileceğini, düzenleyebileceğini, test edebileceğini veya yönetebileceğini kontrol etmenizi sağlar.

Apidog'u bugün deneyin

API Ekipleri İçin RBAC Neden Önemlidir?

API geliştirme genellikle birden fazla rolü içerir:

Geliştiriciler uç noktaları yazar.
QA mühendisleri testleri çalıştırır.
Ürün yöneticileri spesifikasyonları inceler.
Teknik yazarlar dokümantasyon üretir.
Güvenlik ekipleri erişim günlüklerini denetler.

Yapılandırılmış erişim kontrolü yoksa şu sorunlar ortaya çıkar:

Acemi bir geliştirici üretim API spesifikasyonunu yanlışlıkla değiştirir.
Bir yüklenici hassas ödeme uç noktalarını görebilir.
Ayrılmış bir çalışanın hesabı aylarca aktif kalır.
Her kullanıcıya ayrı ayrı izin vermek yönetilemez hale gelir.

Bir API Güvenlik Raporu, API güvenlik olaylarının %61'inin yetkisiz erişim veya aşırı izinlerle ilişkili olduğunu göstermiştir. Temel problem çoğu zaman aynıdır: API varlıkları üzerinde kimin ne yapabileceği yeterince ayrıntılı kontrol edilmez.

RBAC bu problemi şu şekilde çözer:

İzinleri rollere bağlar

Kullanıcı değiştiğinde 50 izni değil, rol atamasını güncellersiniz.
En az ayrıcalık prensibini uygular

Her kullanıcı yalnızca işi için gerekli yetkileri alır.
Denetim izlerini anlamlı hale getirir

Her işlem bir kullanıcıya ve role bağlanabilir.
Ekip büyümesini ölçekler

Yeni ekip üyeleri için tek tek izin kopyalamak yerine rol atarsınız.

Apidog, API geliştirme iş akışları için tasarlanmış üç katmanlı bir izin modeli kullanır.

Üç Seviyeli İzin Hiyerarşisi

API işbirliğinde tek bir “projeye erişebilir” kontrolü çoğu zaman yeterli değildir. Kurumsal yapılarda izinlerin farklı kapsamları vardır:

Seviye	Kapsam	Neyi Kontrol Eder
Kuruluş	Şirket geneli	Faturalandırma, SSO, üye yönetimi, özel rol tanımları
Ekip	Departman / iş birimi	Ekip üyeliği, proje oluşturma, ekip kaynakları
Proje	Bireysel API	Uç noktalar, testler, dokümantasyon, ortamlar, dallar

Örnek senaryo:

Kuruluş: Fintech Şirketi
├── Ekip: Ödemeler
├── Ekip: Kimlik
└── Ekip: Analiz

Bu yapıda:

Ödeme ekibindeki geliştirici Ödeme API'lerine erişmeli.
Kimlik veya Analiz projelerine otomatik erişmemeli.
Kuruluş yöneticisi SSO yapılandırabilmeli.
QA mühendisi test çalıştırabilmeli ama API spesifikasyonunu değiştirmemeli.

Üç seviyeli RBAC iki yaygın hatayı önler:

Aşırı yetkilendirme: Herkese yönetici vermek.
İzin boşlukları: Ekip düzeyini yapılandırıp proje ayrıntılarını atlamak.

Kuruluş Düzeyinde Roller ve İzinler

Kuruluş rolleri, şirket genelindeki ayarları yönetir:

Faturalandırma
SSO yapılandırması
Üye yönetimi
Ekip yönetimi
Özel rol tanımları
Kuruluş kaynakları

Yerleşik Kuruluş Rolleri

Rol	Açıklama	Ana Yetenekler
Kuruluş Sahibi	Kuruluş yaratıcısı, en yüksek yetki	Kuruluşu yeniden adlandırma, aktarma, kapatma, tam yönetim
Kuruluş Yöneticisi	Kuruluş yönetimi	Üyeleri, ekipleri, SSO'yu, özel rolleri ve kaynakları yönetir
Kuruluş Üyesi	Temel katılımcı	Ekip ve proje izinlerine göre çalışır
Faturalandırma Yöneticisi	Finans odaklı rol	Abonelikleri ve faturalandırmayı yönetir

Kuruluş Ayarları İzin Matrisi

Özellik	Kuruluş Sahibi	Kuruluş Yöneticisi	Kuruluş Üyesi	Faturalandırma Yöneticisi
Kuruluş ayarlarına erişim	✅	✅	❌	❌
Kuruluşu yeniden adlandır	✅	✅	❌	❌
Kuruluş sahipliğini aktar	✅	❌	❌	❌
Kuruluşu kapat	✅	❌	❌	❌

Ekip Yönetimi İzin Matrisi

Özellik	Kuruluş Sahibi	Kuruluş Yöneticisi	Kuruluş Üyesi	Faturalandırma Yöneticisi
Yeni ekip oluştur	✅	✅	❌	❌
Ekibi kuruluşa aktar	✅	✅	❌	❌
Ekibi kuruluştan aktar	✅	✅	❌	❌

Üye Yönetimi İzin Matrisi

Özellik	Kuruluş Sahibi	Kuruluş Yöneticisi	Kuruluş Üyesi	Faturalandırma Yöneticisi
Üye davet et	✅	✅	❌	❌
Üyenin kuruluş rolünü değiştir	✅	✅	❌	❌
Üyeleri kaldır	✅	✅	❌	❌

Kuruluş Üyesi rolü bilinçli olarak sınırlıdır. Bu rol kuruluş ayarlarını yönetmez; ekip ve proje seviyesindeki izinlere göre çalışır.

Faturalandırma Yöneticisi bağımsız bir roldür. Bir kullanıcı hem Kuruluş Üyesi hem de Faturalandırma Yöneticisi olabilir. Bu kullanıcı faturalandırmayı yönetebilir ama SSO veya üyeleri yönetemez.

Ekip Düzeyinde Roller ve İzinler

Ekip rolleri, departman veya iş birimi seviyesindeki işlemleri kontrol eder.

Bir ekip şu yapıları temsil edebilir:

Mobil Ekip
Backend Ekibi
QA Ekibi
Ödemeler Ekibi
Platform Ekibi

Yerleşik Ekip Rolleri

Rol	Açıklama	Ana Yetenekler
Ekip Sahibi	Ekip yaratıcısı	Ekibi aktarır/kapatır, tüm ekip ayarlarını yönetir
Ekip Yöneticisi	Ekip operasyonları	Üye davet eder, rol atar, proje oluşturur/siler
Ekip Üyesi	Ekip katılımcısı	Üye detaylarını görüntüler, proje izinlerine göre çalışır
Misafir	Harici işbirlikçi	Ekip yönetimi yok, yalnızca proje erişimi

Ekip Yönetimi İzin Matrisi

İzin	Ekip Sahibi	Ekip Yöneticisi	Ekip Üyesi	Misafir
Ekip üyesi detaylarını görüntüle	✅	✅	✅	❌
Ekip üyelerini davet et	✅	✅	❌	❌
Ekip üyesi rollerini ata/kaldır	✅	✅	❌	❌
Proje rollerini görüntüle	✅	✅	❌	❌
Proje rolleri ekle/düzenle/sil	✅	✅	❌	❌

Ekip Ayarları İzin Matrisi

İzin	Ekip Sahibi	Ekip Yöneticisi	Ekip Üyesi	Misafir
Ekip adını düzenle	✅	✅	❌	❌
Ekibi aktar	✅	❌	❌	❌
Ekibi kapat	✅	❌	❌	❌

Proje Operasyonları İzin Matrisi

İzin	Ekip Sahibi	Ekip Yöneticisi	Ekip Üyesi	Misafir
Yeni proje oluştur	✅	✅	❌	❌
Projeyi kopyala	✅	✅	❌	❌
Projeyi sil/aktar	✅	✅	❌	❌
Proje adını düzenle	✅	✅	❌	❌

Misafir rolü, danışmanlar, yükleniciler veya departmanlar arası işbirlikçiler için kullanışlıdır. Misafirler ekip yönetimi özelliklerine erişmez; yalnızca atandıkları projelerde çalışır.

Proje Düzeyinde Roller ve İzinler

Proje rolleri, günlük API çalışmasının gerçekleştiği seviyeyi kontrol eder:

Uç nokta düzenleme
Test çalıştırma
Ortam yönetimi
Dokümantasyon yayınlama
Proje ayarları
İstek geçmişi
İçe/dışa aktarma

Yerleşik Proje Rolleri

Rol	Açıklama	Kullanım Durumu
Yönetici	Tam proje kontrolü	Proje lideri, API sahibi
Editör	İçeriği değiştirebilir	Geliştiriciler, QA mühendisleri
Salt Okunur	Görüntüleme ve çalıştırma	Ürün yöneticileri, paydaşlar, gözden geçirenler
Yasaklı	Erişim yok	Hassas projeler, kısıtlı kullanıcılar

Proje İzin Kategorileri

Proje izinleri sekiz ana kategoriye ayrılır:

Dal Yönetimi

Sprint dalları, birleştirme istekleri, korumalı dallar, API versiyonları.
Uç Nokta Yönetimi

Uç noktalar, durumlar, şemalar, bileşenler, istekler, çöp kutusu işlemleri.
Otomatik Testler

Test senaryoları, performans testleri, zamanlanmış görevler, test raporları.
Ortam Yönetimi

Genel değişkenler, parametreler, ortamlar, Kasa Sırları.
Dokümantasyon Paylaşımı

Hızlı paylaşım, dokümantasyon sitesi yayınlama.
Proje Ayarları

Temel ayarlar, üye yönetimi, özellik ayarları, bildirimler.
İstek Geçmişi

Yerel ve paylaşılan istek geçmişi.
İçe/Dışa Aktarma

Veri içe aktarma, zamanlanmış içe aktarma, dışa aktarma.

Önemli Proje İzinleri

İzin	Yönetici	Editör	Salt Okunur	Yasaklı
Uç noktaları görüntüle/çalıştır	✅	✅	✅	❌
Uç noktaları ekle/sil/değiştir	✅	✅	❌	❌
Fonksiyonel testleri çalıştır	✅	✅	✅	❌
Test senaryoları ekle/sil/değiştir	✅	✅	❌	❌
Ortam değişkenlerini görüntüle/düzenle	✅	✅	✅	❌
Ortamları ekle/sil/değiştir	✅	✅	❌	❌
Kasa Sırlarına erişim	✅	✅	❌	❌
Dokümantasyon sitesi ayarlarını yayınla	✅	❌	❌	❌
Projeyi klonla	✅	❌	❌	❌
Proje üyelerini yönet	✅	❌	❌	❌

Yasaklı rolü, hassas projeler için önemlidir. Bir kullanıcı ekipte kalabilir ama belirli bir projeye sıfır erişime sahip olabilir. Örneğin ödeme API'lerini yalnızca ilgili ekip üyelerine açmak için kullanılabilir.

Ayrıntılı Kontrol İçin Özel Roller

Yerleşik roller çoğu senaryo için yeterlidir. Ancak kurumsal ekiplerde daha özel izin modellerine ihtiyaç duyulabilir. Apidog'un Kurumsal planı, özel proje rolleri oluşturmayı destekler.

Özel Role Ne Zaman İhtiyaç Duyarsınız?

Örnekler:

QA Mühendisi: Testleri çalıştırabilir ve test senaryolarını değiştirebilir, ancak API spesifikasyonlarını düzenleyemez.
Teknik Yazar: Dokümantasyonu düzenleyebilir, uç noktaları veya ortamları değiştiremez.
Güvenlik Denetçisi: Salt okunur erişim alır, Kasa Sırlarını görüntüleyebilir, değişiklik yapamaz.
Stajyer: Uç noktaları görüntüler ve istek çalıştırır, hiçbir şeyi silemez.

Özel Proje Rolü Oluşturma

Apidog'da özel rol oluşturmak için:

Ekip → Üyeler → Roller ve İzinler yoluna gidin. veya Kuruluş → Üyeler → Roller ve İzinler bölümünü açın.
+ Ekle düğmesine tıklayın.
Rol adını belirleyin.
İzin kategorilerini seçin.
Rolü kaydedin ve test projesinde doğrulayın.

Yapılandırılabilir İzin Kategorileri

Kategori	Ayrıntılı Kontroller
Dal Yönetimi	Dalları görüntüle, dalları birleştir, birleştirme istekleri gönder, korumalı dalları değiştir
Uç Nokta Yönetimi	Görüntüle/çalıştır, ekle/değiştir/sil, kod oluştur, durumları, şemaları, bileşenleri, istekleri yönet
Otomatik Testler	Fonksiyonel testleri çalıştır, performans testlerini çalıştır, senaryoları değiştir, zamanlanmış görevleri yönet
Ortam Yönetimi	Mevcut değerleri görüntüle/düzenle, ekle/değiştir/sil, Kasa Sırlarını yönet
Dokümantasyon	Hızlı paylaşımı görüntüle/değiştir, belge sitelerini önizle, yayınlama ayarlarını yönet
Proje Ayarları	Ayarları görüntüle/değiştir, üyeleri yönet, bildirimleri yapılandır, içe/dışa aktarmayı yönet
İstek Geçmişi	Yerel geçmişi görüntüle, geçmişi paylaş, paylaşılan geçmişi görüntüle/sil

Özel Rol İçin Uygulama Önerileri

Mevcut rolden kopyalayarak başlayın

Sıfırdan oluşturmak yerine Editör veya Salt Okunur rolünü kopyalayın.
“Tüm İzinler” kutularını dikkatli kullanın

Bir modül için tüm izinleri seçerseniz gelecekte eklenen izinler de otomatik gelebilir.
Üretime almadan önce test edin

Test projesi oluşturun, rolü atayın ve davranışı doğrulayın.
Rol adlandırma standardı belirleyin

Örnek: QA-Test-Editor, Docs-Editor, Security-ReadOnly.
Üç ayda bir gözden geçirin

Rol sürünmesini ve gereksiz izinleri temizleyin.

Kurumsal Güvenlik Özellikleri

RBAC tek başına yeterli değildir. Kurumsal API ekipleri genellikle kimlik yönetimi, otomatik sağlama ve sır yönetimi gibi ek güvenlik özelliklerine ihtiyaç duyar.

Apidog, RBAC ile birlikte çalışan şu kurumsal güvenlik özelliklerini destekler:

SSO
SCIM
Grup eşlemesi
Kasa Sırları
Denetim günlükleri

Tek Oturum Açma: SSO

SAML 2.0 ile SSO, kimlik doğrulamayı merkezi hale getirir.

Desteklenen kimlik sağlayıcı örnekleri:

Microsoft Entra ID / Azure Active Directory
Okta
Google Workspace
OneLogin
Özel SAML 2.0 sağlayıcıları

SSO RBAC İçin Neden Önemlidir?

Yerel parola risklerini azaltır

Kullanıcılar kurumsal kimlik bilgileriyle giriş yapar.
Kimlik yönetimini merkezileştirir

Kullanıcı ekleme ve kaldırma IdP üzerinden yönetilir.
MFA uygulamasını kolaylaştırır

IdP seviyesindeki çok faktörlü kimlik doğrulama Apidog erişimine de yansır.
Onboarding sürecini sadeleştirir

Yeni çalışanlar ayrı hesap oluşturmadan erişebilir.

SCIM Sağlama

SCIM, kullanıcı yaşam döngüsünü otomatikleştirir.

Yetenek	Ne Yapar
Kullanıcı ekle	IdP kullanıcı oluşturduğunda kullanıcı Apidog kuruluşuna eklenir
Kullanıcı kaldır	IdP kullanıcıyı sildiğinde Apidog erişimi kaldırılır
Hesapları bağla	SSO kimlikleri mevcut Apidog hesaplarıyla eşleştirilir

SCIM Avantajları

Eski çalışanların erişimi hızlıca kaldırılır.
Manuel davet/kaldırma iş akışları azalır.
Uyumluluk için erişim geçmişi netleşir.
Unutulmuş hesap riski düşer.

Ekiplere Grup Eşlemesi

Apidog, SAML grup eşlemesini destekler. Böylece IdP grupları Apidog ekiplerine bağlanabilir.

Kurulum akışı:

IdP üzerinde grup iddialarını yapılandırın.
Her IdP grubunu bir Apidog ekibine eşleyin.
Her grup için ekip rolünü belirleyin.
Pilot kullanıcılarla test edin.

Örnek:

Azure AD grubu: API Geliştiricileri
→ Apidog ekibi: Backend Ekibi
→ Rol: Ekip Üyesi

Azure AD grubu: API Yöneticileri
→ Apidog ekibi: Platform Ekibi
→ Rol: Ekip Yöneticisi

Kullanıcılar SSO ile giriş yaptığında doğru ekiplere uygun izinlerle otomatik olarak katılır.

Kasa Sırları

Kasa Sırları / Vault Secrets, API anahtarları, parolalar ve token değerlerini merkezi olarak yönetmek için kullanılır.

Özellik	Güvenlik Faydası
Şifreli depolama	API anahtarları ve token'lar ortam dosyaları yerine şifreli depolanır
Referans tabanlı erişim	Kullanıcılar sırları isimle referans alır, gerçek değeri görmez
Rol tabanlı görünürlük	Kasa Sırlarını kimlerin yönetebileceği RBAC ile belirlenir
Denetim izi	Sır erişimleri uyumluluk için izlenebilir

Kasa Sırları vs Yerel Ortam Dosyaları

Yaklaşım	Risk
Yerel ortam dosyaları	Sırlar proje erişimi olan herkes tarafından görülebilir, Git'e sızabilir
Kasa Sırları	Merkezi, şifreli, rol kontrollü ve denetlenebilir

Apidog'da RBAC Nasıl Kurulur?

Aşağıdaki örnek, tipik bir API organizasyonu için uygulanabilir RBAC kurulumu gösterir.

Adım 1: Ekip Yapınızı Tanımlayın

Önce kuruluş, ekip ve proje yapınızı modelleyin:

Organizasyon: Şirketiniz
├── Ekip: Ödemeler
│   ├── Proje: Ödeme Ağ Geçidi API'si
│   ├── Proje: Sahtekarlık Tespit API'si
│   └── Proje: Faturalandırma Hizmeti API'si
├── Ekip: Kimlik
│   ├── Proje: Kimlik Doğrulama Hizmeti API'si
│   └── Proje: Kullanıcı Yönetimi API'si
└── Ekip: Analiz
    ├── Proje: Metrikler API'si
    └── Proje: Raporlama API'si

Adım 2: Kuruluş Rollerini Atayın

Önerilen başlangıç dağılımı:

Rol	Kimlere Verilmeli
Kuruluş Sahibi	CTO, CEO veya Platform Lideri gibi 1 kişi
Kuruluş Yöneticisi	Mühendislik yöneticileri, güvenlik liderleri
Kuruluş Üyesi	Geliştiriciler, QA, PM'ler, teknik yazarlar
Faturalandırma Yöneticisi	Finans veya satın alma sorumluları

Adım 3: Ekip Rollerini Yapılandırın

Her ekip için sahip, yönetici ve üyeleri belirleyin.

Ekip	Ekip Sahibi	Ekip Yöneticisi	Ekip Üyeleri
Ödemeler	Ödemeler Lideri	Ödemeler Yöneticisi	5 geliştirici, 2 QA
Kimlik	Kimlik Lideri	Kimlik Yöneticisi	3 geliştirici, 1 QA
Analiz	Analiz Lideri	Analiz Yöneticisi	2 geliştirici

Adım 4: Proje Rollerini Atayın

Proje seviyesinde sorumluluğa göre en az ayrıcalıklı rolü seçin.

Kişi	Ödeme Ağ Geçidi API'si	Sahtekarlık Tespit API'si	Kimlik Doğrulama Hizmeti API'si
Kıdemli Geliştirici A	Yönetici	Editör	Yasaklı
Kıdemli Geliştirici B	Editör	Yönetici	Yasaklı
Acemi Geliştirici C	Editör	Salt Okunur	Yasaklı
QA Mühendisi	Editör	Editör	Yasaklı
Ürün Yöneticisi	Salt Okunur	Salt Okunur	Yasaklı
Yüklenici	Editör	Yasaklı	Yasaklı

Adım 5: Üyeleri Önceden Belirlenmiş Rollerle Davet Edin

Apidog'da kullanıcı davet ederken rolleri baştan atayabilirsiniz:

Ekip daveti

Kullanıcıyı ekip rolü ve varsayılan proje rolüyle davet edin.
Proje daveti

Kullanıcıyı belirli projeye proje rolüyle davet edin. Kullanıcı ekibe otomatik olarak üye olabilir.

Harici işbirlikçiler için öneri:

Proje: Ödeme Ağ Geçidi API'si
Rol: Editör
Diğer Projeler: Yasaklı

Bu yapı, yüklenicinin yalnızca atanmış projeyi görmesini sağlar.

Adım 6: SSO ve SCIM'i Yapılandırın

Kurumsal kullanımda önerilen akış:

Kuruluş Ayarlarında SAML SSO'yu etkinleştirin.
IdP panelinden SCIM belirtecini yapılandırın.
IdP gruplarını Apidog ekiplerine eşleyin.
Önce pilot bir grupla test edin.
Sonra tüm kuruluşa yayınlayın.

API İşbirliği Güvenliği İçin En İyi Uygulamalar

1. En Az Ayrıcalık Prensibini Uygulayın

Varsayılan olarak minimum izin verin, ihtiyaç oldukça artırın.

Öneriler:

Yeni ekip üyeleri: Salt Okunur
Deneyimli geliştiriciler: Editör
Proje liderleri: Yönetici
Yükleniciler: Çoğu projede Yasaklı, atanmış projede Editör veya Salt Okunur

2. Geliştirme ve Üretim Erişimini Ayırın

Geliştirme, hazırlık ve üretim ortamlarını ayrı proje veya dallarla yönetin.

Ortam	Geliştirici Erişimi	QA Erişimi	Yönetici Erişimi
Geliştirme	Editör	Editör	Yönetici
Hazırlık	Salt Okunur	Editör	Yönetici
Üretim	Yasaklı	Salt Okunur	Yönetici

3. Uzman Roller İçin Özel Roller Kullanın

Genel roller her zaman doğru eşleşmeyebilir.

Örnek özel roller:

Security-ReadOnly: Güvenlik ekibi için salt okunur + gerekli sır görünürlüğü.
Docs-Editor: Teknik yazarlar için dokümantasyon düzenleme.
QA-Test-Editor: Testleri düzenleme, API spesifikasyonlarını değiştirmeme.
Performance-Tester: Performans testlerini çalıştırma ve raporlama.

4. İzinleri Üç Ayda Bir Gözden Geçirin

RBAC “kur ve unut” yaklaşımı değildir.

Üç aylık kontrol listesi:

Kullanıcıların hâlâ doğru rollerde olduğunu doğrulayın.
Rol sürünmesini kontrol edin.
Yüklenici erişimlerini gözden geçirin.
Ayrılan çalışanların SCIM ile kaldırıldığını doğrulayın.
Özel rolleri güncelleyin.

5. Rol Tanımlarını Belgeleyin

Basit bir dahili doküman oluşturun:

# API Erişim Rolleri

## Yönetici
- Proje ayarlarını yönetebilir
- Üye ekleyebilir/kaldırabilir
- Dokümantasyon yayınlayabilir

## Editör
- Uç noktaları düzenleyebilir
- Test senaryoları oluşturabilir
- Ortamları düzenleyebilir

## Salt Okunur
- Uç noktaları görüntüleyebilir
- Testleri çalıştırabilir
- Değişiklik yapamaz

## Yasaklı
- Projeye erişemez

Ayrıca şu bilgileri ekleyin:

Rol değişikliği nasıl istenir?
Onaylayan kişi kimdir?
Acil erişim süreci nedir?
Erişim anlaşmazlığı nasıl eskale edilir?

6. Denetim Günlüğünü Kullanın

Kurumsal planlarda denetim günlükleri şu sorulara yanıt verir:

Kim erişti?
Neye erişti?
Ne zaman erişti?
Hangi işlemi yaptı?
Rol ne zaman değiştirildi?

Denetim günlüklerini şu amaçlarla kullanabilirsiniz:

Uyumluluk raporlaması
Güvenlik olayı incelemesi
Gereksiz izinleri tespit etme
Rol optimizasyonu

RBAC Karşılaştırması: Apidog vs Diğer Araçlar

Özellik	Apidog	Postman	SwaggerHub	Bruno
İzin Seviyeleri	3: Kuruluş/Ekip/Proje	2: Kuruluş/Ekip	2: Kuruluş/Çalışma Alanı	1: Git tabanlı
Yerleşik Roller	12 rol	5 rol	4 rol	Yok, Git izinleri
Özel Roller	✅ Kurumsal	✅ Kurumsal	✅ Kurumsal	❌
SSO/SAML	✅	✅	✅	❌
SCIM Sağlama	✅	✅	❌	❌
Grup Eşlemesi	✅	✅	✅	❌
Kasa Sırları	✅	✅ Kurumsal	❌	❌
Proje İzolasyonu	✅ Yasaklı rolü	Sınırlı	Sınırlı	Git tabanlı
Harici İşbirlikçi Kontrolü	✅ Misafir + Yasaklı	Sınırlı	Sınırlı	Git erişim kontrolü

Apidog'un RBAC Avantajları

Üç seviyeli hiyerarşi

Kuruluş, ekip ve proje kapsamlarını ayrı ayrı yönetir.
Yasaklı rolü

Ekip içinde kalıp belirli projeye erişimi tamamen kapatabilirsiniz.
Misafir rolü

Harici işbirlikçileri ekip yönetiminden izole eder.
SCIM entegrasyonu

Kullanıcı sağlama ve devre dışı bırakma otomatikleşir.
Birleşik API platformu

RBAC; tasarım, test, dokümantasyon ve mocking iş akışlarıyla birlikte çalışır.

Apidog RBAC Ne Zaman Uygundur?

Apidog RBAC özellikle şu ekipler için uygundur:

Birden fazla API ekibi olan kuruluşlar
SSO, SCIM ve denetlenebilirlik gerektiren kurumsal yapılar
Geliştirici, QA, PM, güvenlik ve teknik yazarların birlikte çalıştığı ekipler
Harici yüklenicilerle çalışan API ekipleri
Hassas API'lerde net erişim sınırları gerektiren organizasyonlar

Sonuç

Rol Tabanlı Erişim Kontrolü, API işbirliğini daha güvenli ve yönetilebilir hale getirir. RBAC olmadan ekip büyüdükçe izin karmaşıklığı, güvenlik riski ve uyumluluk yükü artar. Doğru RBAC modeliyle ekip üyelerini, yüklenicileri ve paydaşları kontrolü kaybetmeden sisteme dahil edebilirsiniz.

Özetle:

Kuruluş → Ekip → Proje hiyerarşisi gerçek ekip yapılarıyla uyumludur.
12 yerleşik rol, standart erişim senaryolarını hızlıca kapsar.
Özel proje rolleri, uzmanlaşmış görevler için ayrıntılı izin sağlar.
SSO ve SCIM, kimlik yönetimini kurumsal sistemlerle entegre eder.
Kasa Sırları, kimlik bilgilerini merkezi ve rol kontrollü şekilde yönetir.
Yasaklı rolü, hassas projeler için açık erişim engelleme sağlar.
Grup eşlemesi, IdP gruplarına göre ekip atamasını otomatikleştirir.

Apidog'un RBAC sistemi, küçük ekiplerden büyük kurumsal API organizasyonlarına kadar erişim kontrolünü daha uygulanabilir ve denetlenebilir hale getirmek için kullanılabilir.

SSS: API Ekipleri İçin Rol Tabanlı Erişim Kontrolü

API geliştirmede Rol Tabanlı Erişim Kontrolü nedir?

API geliştirmede RBAC, erişim haklarının bireysel kullanıcılara değil rollere atandığı bir izin modelidir. Kullanıcılar Yönetici, Editör veya Salt Okunur gibi roller alır. Bu roller, hangi API kaynaklarını görüntüleyebileceklerini, değiştirebileceklerini, test edebileceklerini veya yönetebileceklerini belirler.

API işbirliği neden üç seviyeli izinlere ihtiyaç duyar?

API ekipleri kuruluş, ekip ve proje seviyelerinde çalışır. Kuruluş seviyesi SSO ve faturalandırmayı; ekip seviyesi üyelik ve proje oluşturmayı; proje seviyesi ise uç nokta, test ve dokümantasyon işlemlerini yönetir. Üç seviyeli RBAC bu yapıyı doğrudan karşılar.

Kuruluş Yöneticisi ile Ekip Yöneticisi arasındaki fark nedir?

Kuruluş Yöneticisi şirket genelindeki ayarları yönetir: üyeler, ekipler, SSO, özel roller ve kaynaklar. Ekip Yöneticisi ise belirli bir ekip içindeki üyeleri, projeleri ve ekip kaynaklarını yönetir.

Yasaklı proje rolü nasıl çalışır?

Yasaklı rolü, belirli bir projeye erişimi tamamen kapatır. Kullanıcı ekipte kalabilir ancak Yasaklı olduğu projeyi göremez ve proje içeriğine erişemez. Bu, ödeme veya güvenlik API'leri gibi hassas projeler için kullanışlıdır.

Misafir ekip rolü ne işe yarar?

Misafir rolü, proje erişimine ihtiyaç duyan ancak ekip yönetmemesi gereken harici işbirlikçiler için kullanılır. Misafirler üye detaylarını göremez, üye davet edemez ve ekip ayarlarını değiştiremez.

Belirli izinlerle özel roller oluşturabilir miyim?

Evet. Apidog Kurumsal planlarında özel proje rolleri oluşturabilirsiniz. Dal yönetimi, uç nokta yönetimi, testler, ortam yönetimi, dokümantasyon, proje ayarları, istek geçmişi ve içe/dışa aktarma gibi kategorilerde ayrıntılı izinler tanımlanabilir.

SSO entegrasyonu RBAC ile nasıl çalışır?

SSO, kimlik doğrulamayı Okta veya Microsoft Entra ID gibi kimlik sağlayıcılar üzerinden merkezi hale getirir. Kullanıcılar kurumsal kimlikleriyle giriş yapar. Grup eşlemesiyle IdP grupları Apidog ekipleri ve rolleriyle ilişkilendirilebilir.

SCIM sağlama nedir?

SCIM, kullanıcı yaşam döngüsünü otomatikleştirir. Yeni çalışanlar IdP üzerinden otomatik olarak Apidog'a eklenebilir. Ayrılan çalışanların erişimi de otomatik kaldırılabilir. Bu, unutulmuş hesap riskini azaltır.

Kasa Sırları RBAC ile nasıl çalışır?

Kasa Sırları, API anahtarları, parolalar ve token'ları merkezi ve şifreli şekilde saklar. Kullanıcılar gerçek değeri görmek yerine sırları isimle referans alır. RBAC, bu sırları kimlerin görüntüleyebileceğini veya yönetebileceğini belirler.

Yükleniciler Kuruluş Üyesi mi yoksa Misafir mi olmalı?

Yükleniciler genellikle ekip düzeyinde Misafir, proje düzeyinde ise ihtiyaçlarına göre Editör veya Salt Okunur olmalıdır. Görünürlüklerini yalnızca atanmış projelerle sınırlamak için diğer projelerde Yasaklı rolü kullanılabilir.

Stoplight + Postman vs Apidog: API Tasarımı, Dokümantasyonu ve Testi için Tek Platform

Tobias Hoffmann — Fri, 05 Jun 2026 08:53:38 +0000

Ekibiniz OpenAPI tasarımı ve belgeleri için Stoplight, koleksiyonlar ve testler için Postman kullanıyorsa sorun tanıdıktır: API spesifikasyonu ve testler zamanla ayrışır. Stoplight Postman alternatifi arıyorsanız, muhtemelen aynı API sözleşmesi için iki araç, iki fatura ve iki doğruluk kaynağı yönetmekten yoruldunuz. Apidog, OpenAPI spesifikasyonunu tasarım, dokümantasyon, mock sunucu ve otomatik testler için tek doğruluk kaynağı olarak kullanır.

Apidog'u bugün deneyin

Bu yazı, Stoplight ve Postman’ın güçlü olduğu alanları, iki araçlı kurulumun nerede sürtünme yarattığını ve Apidog’da birleşmenin ekibiniz için ne zaman mantıklı olduğunu uygulama odaklı şekilde inceler. Bu genel bir “alternatifler listesi” değil; mevcut API geliştirme yığınını değiştirme değerlendirmesidir. Spesifikasyon öncelikli yaklaşımı daha derin incelemek için Spesifikasyon Öncelikli API Geliştirme Nedir? yazısına bakabilirsiniz.

İki araç sorunu

Stoplight ve Postman API yaşam döngüsünün farklı parçalarını iyi çözer:

Stoplight: görsel OpenAPI düzenleyici, Git destekli spesifikasyon deposu, otomatik referans dokümantasyonu.
Postman: koleksiyon çalıştırıcı, ortam değişkenleri, pre-request script’ler, test panosu ve CI için Newman.

Birlikte tasarımdan teste kadar geniş kapsama sağlarlar. Ancak ayrı çalıştıklarında üç pratik sorun oluşur.

1. Spesifikasyon-test sapması

OpenAPI spesifikasyonunuz Stoplight ile Git deposunda yaşar. Postman koleksiyonunuz Postman bulutunda yaşar.

Bir geliştirici spesifikasyondaki request body şemasını değiştirirse Postman testleri otomatik güncellenmez. QA ekibi eski koleksiyonu yeni endpoint’e karşı çalıştırdığında test başarısız olur. Bu ürün hatası değil, araçlar arasındaki senkronizasyon boşluğudur.

2. Tekrarlanan bakım

Şu bilgiler genellikle iki kez tanımlanır:

Path parametreleri
Base URL’ler
Ortamlar: staging, production, EU region vb.
Kimlik doğrulama şemaları
Response şemaları

Tipik iş akışı şöyle görünür:

OpenAPI spesifikasyonunu oluştur.
Swagger veya Stoplight Docs’ta görüntüle.
Test etmek için Postman’a aktar.
Spesifikasyon değişince Postman koleksiyonunu manuel güncelle.
Ortam değişikliklerini iki yerde tekrar uygula.

Bu “aktar ve yamala” döngüsü büyüyen ekiplerde hızla maliyet üretir.

3. İki fatura, tek API sözleşmesi

Stoplight platform katmanı ve dokümantasyonu kapsar. Postman koleksiyonlar, test çalıştırmaları ve monitoring tarafını kapsar.

Kuruluşunuz ikisini birlikte kullanıyorsa, tek API sözleşmesini yönetmek için iki ayrı platform maliyeti oluşur.

Stoplight neyi iyi yapar?

Stoplight’ın en güçlü tarafı görsel OpenAPI düzenleyicisidir. YAML/JSON yazarken doğrulama yapar, Spectral ile stil kuralları uygular ve teknik olmayan paydaşlar için okunabilir bir form görünümü sağlar.

Git entegrasyonu Git-native çalışır:

Her kayıt GitHub veya GitLab deposuna commit olur.
Branch protection kuralları normal şekilde uygulanır.
OpenAPI dosyaları repository içinde kalır.

Stoplight Docs da güçlüdür:

Referans dokümantasyonu otomatik oluşturur.
Özel domain ile yayınlanabilir.
toc.json ile içerik yapısı kontrol edilebilir.
Dahili endpoint’ler işaretlenebilir.
“Try it” API explorer gömülebilir.

Ancak Stoplight’ın sınırı yürütme tarafındadır. Yerleşik test runner, sözleşme doğrulama motoru veya CI test raporlama akışı sağlamaz. Spesifikasyonu tasarladıktan sonra test tarafı başka bir araca devredilir.

Postman neyi iyi yapar?

Postman’ın koleksiyon modeli çoğu geliştiriciye tanıdıktır:

Koleksiyonlar istekleri gruplandırır.
Ortamlar değişken ikamesi sağlar.
Test sekmesi pm.test() ile JavaScript doğrulamalarını çalıştırır.
Collection Runner ve Newman CLI testleri CI pipeline’larında çalıştırabilir.

Örnek Postman testi:

pm.test("Durum 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Yanıtta orderId var", function () {
  const json = pm.response.json();
  pm.expect(json).to.have.property("orderId");
});

Postman monitoring, canlı endpoint’lere karşı planlı koleksiyon çalıştırmaları yapar ve hata durumunda uyarı verebilir. Üretim uptime kontrolleri yapan ekipler için bu pratik bir özelliktir.

Zayıf nokta ise spesifikasyondan kopuk çalışmasıdır. OpenAPI’den içe aktarılan koleksiyonlar varsayılan olarak ayrışır. Koleksiyonu spesifikasyonla senkron tutmak için ya manuel yeniden içe aktarma ya da özel senkronizasyon script’i gerekir.

Platform karşılaştırması: Stoplight vs Postman vs Apidog

Aşağıdaki tablo, temel API yaşam döngüsü yeteneklerini üç araç arasında karşılaştırır.

Yerel: Özellik temel iş akışının birinci sınıf parçasıdır.
Kısmi: Özellik vardır ancak manuel adım veya workaround gerektirir.
Hayır: Araç bu yeteneği kapsamaz.

Yetenek	Stoplight	Postman	Apidog
Görsel OpenAPI düzenleyici	Yerel	Kısmi	Yerel
Spectral / lint kuralları	Yerel	Hayır	Yerel
Git depo senkronizasyonu: GitHub, GitLab	Yerel	Hayır	Yerel: Spec-First Modu, beta
Branch tabanlı spesifikasyon iş akışları	Yerel	Hayır	Yerel
Otomatik referans dokümantasyonu	Yerel	Kısmi	Yerel
Etkileşimli dokümantasyon: try it	Yerel	Hayır	Yerel
Özel doküman erişim kontrolü	Yerel	Hayır	Deneme sürümünde doğrulamaya değer
Spesifikasyondan mock sunucu	Kısmi: Prism	Kısmi	Yerel
İstek koleksiyonu çalıştırıcısı	Hayır	Yerel	Yerel
JavaScript test script’leri	Hayır	Yerel	Yerel
Görsel doğrulama düzenleyici	Hayır	Hayır	Yerel
Ortam değişkeni yönetimi	Hayır	Yerel	Yerel
CI/CD entegrasyonu: Newman / CLI	Hayır	Yerel	Yerel
Spesifikasyondan sözleşme testi	Hayır	Hayır	Yerel
Çapraz proje şema yeniden kullanımı	Kısmi	Hayır	Deneme sürümünde doğrulamaya değer
SSO / SCIM	Evet: Enterprise	Evet: Enterprise	Gereksinimlerinize göre kontrol edin
Denetim günlükleri	Evet	Evet	Gereksinimlerinize göre kontrol edin

“Deneme sürümünde doğrulamaya değer” olan alanları gerçek ekip yapınızla test edin. Özellikle çapraz proje bileşen yeniden kullanımı ve rapor görünürlüğü izinleri, demo verisiyle değil gerçek workspace yapısıyla değerlendirilmelidir.

Apidog’un Spec-First Modu neyi değiştirir?

Apidog’un Spesifikasyon Öncelikli Modu, mevcut GitHub veya GitLab deponuzu yetkili OpenAPI kaynağı olarak bağlar.

Tek seferlik OpenAPI import yerine çalışma alanı Git commit’leriyle senkron kalır. Bir geliştirici path parametresini değiştiren PR’ı merge ettiğinde Apidog değişikliği alır. Mock sunucular, dokümantasyon ve test doğrulamaları aynı yeni şemaya göre güncellenir.

Stoplight + Postman kullanan ekip için pratik akış şöyle olur:

Mevcut OpenAPI repository’nizi koruyun.
Apidog’da Spec-First Mode ile GitHub veya GitLab bağlantısı kurun.
Spesifikasyondan mock sunucu üretin.
Frontend ekibine backend hazır olmadan gerçekçi response’lar sağlayın.
Spesifikasyon şemasından test senaryoları oluşturun.
Gerekirse ek doğrulamalar ekleyin.
Testleri CI’da Apidog CLI ile çalıştırın.
Dokümantasyonu aynı spesifikasyondan otomatik güncel tutun.

Kurulum detayları için Spesifikasyon Öncelikli Mod kılavuzu kullanılabilir. Spec-first ve design-first yaklaşım farkları için Spesifikasyon Öncelikli mi Yoksa Tasarım Öncelikli mi: Hangi Apidog Modunu Kullanmalısınız? yazısı da yararlıdır.

Çalışan örnek: OpenAPI’den sözleşme testi

Aşağıdaki endpoint’i düşünün:

GET /orders/{orderId}

Postman’da bu endpoint için testleri manuel yazarsınız:

// Postman test sekmesi: manuel yazılır ve spesifikasyondan ayrı yaşar
pm.test("Durum 200", function () {
  pm.response.to.have.status(200);
});

pm.test("Yanıtın orderId'si var", function () {
  const json = pm.response.json();
  pm.expect(json).to.have.property("orderId");
  pm.expect(json.orderId).to.be.a("string");
});

Bu test, OpenAPI spesifikasyonunda zaten bulunan bilgiyi tekrar eder. Birisi şemaya yeni bir required alan eklerse ancak Postman koleksiyonunu güncellemezse testler eksik kalır.

Spec-First yaklaşımda doğrulamanın kaynağı OpenAPI dosyasıdır:

# Git deponuzdaki OpenAPI parçacığı: örn. openapi/orders.yaml
paths:
  /orders/{orderId}:
    get:
      summary: Kimliğe göre sipariş al
      parameters:
        - name: orderId
          in: path
          required: true
          schema:
            type: string
      responses:
        "200":
          description: Sipariş bulundu
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/Order"

components:
  schemas:
    Order:
      type: object
      required:
        - orderId
        - status
        - createdAt
      properties:
        orderId:
          type: string
        status:
          type: string
          enum: [pending, processing, shipped, delivered]
        createdAt:
          type: string
          format: date-time

Bu spesifikasyon senkronize edildiğinde Apidog, 200 response şemasını test senaryosunda sözleşme doğrulaması olarak kullanır.

Pratik sonuç:

Response içinde status eksikse test başarısız olur.
createdAt geçerli date-time formatında değilse doğrulama yakalar.
status enum dışı bir değer döndürürse sözleşme testi hata verir.
Manuel Postman testini her şema değişikliğinde güncellemeniz gerekmez.

OpenAPI ve Git ilişkisini yapılandırmak için Bir OpenAPI Spesifikasyonunu Git ile Nasıl Sürüm Kontrol Edersiniz? yazısına bakabilirsiniz.

Geçişten önce doğrulamanız gerekenler

Kurumsal ölçekte platform konsolidasyonu yapmadan önce aşağıdaki alanları gerçek verinizle test edin.

Rapor görünürlüğü izinleri

CI test raporlarını belirli ekipler veya projelerle sınırlayabiliyor musunuz?

Kontrol listesi:

Proje bazlı rapor erişimi
Takım bazlı yetkilendirme
Paylaşılan workspace’lerde görünürlük sınırları
Harici paydaş erişimi

SSO ve SCIM sağlama

Apidog SSO destekler. Ancak SCIM otomatik kullanıcı sağlama, grup senkronizasyonu ve kullanıcı kaldırma davranışını kimlik sağlayıcınıza karşı test edin.

Referans olarak SCIM RFC kullanılabilir.

Test edilmesi gerekenler:

Yeni kullanıcı otomatik oluşturuluyor mu?
Grup değişiklikleri doğru yansıyor mu?
Kullanıcı devre dışı bırakılınca erişim kaldırılıyor mu?
Rol eşlemeleri beklediğiniz gibi çalışıyor mu?

Çapraz proje şema yeniden kullanımı

Birden fazla API projesinde ortak $ref şemalarınız varsa Apidog’un workspace modelini test edin.

Örnek durumlar:

$ref: "../shared/schemas/ErrorResponse.yaml"

veya:

$ref: "https://example.com/schemas/customer.yaml#/Customer"

Doğrulamanız gerekenler:

Dosyalar arası $ref çözümlemesi
Mono-repo yapıları
Çoklu repository yapıları
Paylaşılan component güncellemelerinin projelere etkisi

Denetim günlükleri

Uyumluluk gereksinimleriniz varsa şu bilgileri kontrol edin:

Spesifikasyon değişiklikleri loglanıyor mu?
API erişimleri izleniyor mu?
Log formatı dış sistemlere aktarılabilir mi?
Saklama süresi gereksinimlerinizi karşılıyor mu?

Bu maddeler Apidog’dan kaçınmak için değil, herhangi bir platform geçişinde doğru riskleri erken görmek için kullanılmalıdır.

İki aracı ne zaman tutmalı?

Tek platforma geçmek, spesifikasyon-test sapması ve çift bakım maliyeti geçiş maliyetinden yüksek olduğunda mantıklıdır. Ancak bazı durumlarda Stoplight + Postman yığınını korumak daha doğru olabilir.

İki araçlı yapı şu durumlarda mantıklı kalabilir:

Stoplight Docs dağıtımınız teknik yazarlar tarafından yönetilen özel toc.json yapısıyla derin özelleştirilmiştir.
Postman koleksiyonunuzda yüzlerce pre-request script ve dinamik değişken zinciri vardır.
Üretim uptime kontrolleri için Postman monitors kullanıyorsunuzdur.
Newman JSON çıktısı etrafında özel dashboard veya raporlama entegrasyonu kurmuşsunuzdur.
Geçiş için ekibin yeniden eğitim maliyeti kısa vadede çok yüksektir.

Özellikle Postman tarafında daha geniş alternatifleri değerlendirmek isterseniz API Testi için En İyi Postman Alternatifleri yazısı açık kaynak seçenekleri de kapsar.

Sıkça Sorulan Sorular

Apidog, Stoplight Studio’nun görsel OpenAPI düzenleyicisinin yerini alır mı?

Evet. Apidog, OpenAPI şemaları için görsel düzenleyici, gerçek zamanlı doğrulama ve lint kuralları sağlar.

Ancak ekibiniz repository içindeki özel .spectral.yaml kurallarına güveniyorsa, Apidog’un linting davranışının bu kuralları kapsadığını geçişten önce doğrulayın.

Apidog mevcut GitHub deposuyla yeniden import yapmadan senkronize olabilir mi?

Apidog’un Spec-First Modu, şu anda beta aşamasında, GitHub veya GitLab deposuna bağlanır ve çalışma alanını commit’lerle senkron tutar. Mevcut OpenAPI repository’nizi kaldırmanız gerekmez.

Spesifikasyonu Git’te tutma yaklaşımı için Kod Olarak API Spesifikasyonu yazısına bakabilirsiniz. Ardından bağlantı adımları ve beta sınırlamaları için Apidog dokümantasyonunu kontrol edin.

Apidog CI’da Newman tarzı CLI test çalıştırmalarını destekliyor mu?

Apidog’un kendi CLI aracı vardır. Test senaryolarını çalıştırabilir ve rapor üretebilir.

Mevcut pipeline’ınız şu komutu kullanıyorsa:

newman run collection.json

bunu Apidog CLI eşdeğeriyle değiştirmeniz gerekir. Çıktı formatı farklı olabileceği için Newman JSON çıktısına bağlı dashboard veya raporlama entegrasyonlarını ayrıca değerlendirmeniz gerekir.

Postman pre-request script’leri ve dinamik değişkenleri ne olacak?

Apidog pre-request script’leri ve dinamik değişkenleri destekler. Mock data üreticileri de kullanılabilir.

Ancak Postman koleksiyonunuz yoğun şekilde şu API’lere bağlıysa:

pm.variables.set("token", token);
pm.environment.get("baseUrl");

script’lerin taşınması gerekir. Mantık çoğunlukla aktarılabilir, fakat sözdizimi ve çalışma bağlamı bazı yerlerde farklılık gösterebilir.

Apidog’un Spec-First Modu üretim için hazır mı?

Spec-First Mod şu anda beta aşamasındadır. Temel işlevler çalışır, ancak büyük mono-repo spesifikasyonları, dosyalar arası iç içe $ref çözümlemesi ve CI durum raporlaması gibi uç durumlar için gerçekçi bir proof of concept çalıştırmanız gerekir.

Sonuç

Stoplight ve Postman gerçek problemleri çözer, ancak bunları iki ayrı yerde çözer. Spesifikasyon ve testler farklı araçlarda yaşadığında sapma istisna değil, varsayılan sonuç olur.

Apidog’un Spec-First Modu, tek platforma geçiş için pratik bir yol sunar:

Git doğruluk kaynağı olarak kalır.
OpenAPI spesifikasyonu merkezi kaynak olur.
Dokümantasyon aynı şemadan üretilir.
Mock sunucular spesifikasyondan oluşturulur.
Testler ve sözleşme doğrulamaları spesifikasyona bağlı kalır.
CI raporları aynı API sözleşmesine göre çalışır.

Geçiş kararı vermeden önce özellikle SSO, rapor izinleri, denetim günlükleri ve çapraz proje şema yeniden kullanımı alanlarını proof of concept içinde test edin.

Apidog’un Spec-First Modunu denemek için OpenAPI deponuzu GitHub veya GitLab’dan bağlayabilir, aynı spesifikasyondan canlı dokümantasyon ve mock sunucu oluşturabilirsiniz. Başlamak için Apidog’u indirin veya Spesifikasyon Öncelikli Mod sayfasını ziyaret edin.

OpenAPI İş Birliği Git'i Bırakmadan: Dosya Tabanlı Ekipler Nasıl Birlikte Çalışır

Tobias Hoffmann — Fri, 05 Jun 2026 07:31:59 +0000

OpenAPI ekip işbirliği, spesifikasyon Git'e taşındığında genellikle zorlaşır. Sorun Git'in yanlış yer olması değil; tam tersine, spesifikasyon için doğru doğruluk kaynağı olmasıdır. Sorun, Git inceleme araçlarının API tasarımına katkı veren QA, ön uç ve ürün ekiplerinden çok kod inceleyen mühendisler için tasarlanmış olmasıdır.

Apidog'u bugün deneyin

Ekibiniz OpenAPI spesifikasyonlarını bir depoda YAML veya JSON olarak tutuyorsa, muhtemelen şu tabloyu görmüşsünüzdür: spesifikasyon sürüm kontrollüdür, PR ile incelenebilir durumdadır; ancak mühendis olmayan ekip üyeleri hâlâ tarayıcıda Stoplight önizlemesine bakar, sorularını Slack DM üzerinden sorar ve test etmeye başlamadan önce geliştiricilerin dosyayı güncellemesini bekler.

api-spec-as-code yaklaşımı, Git'in neden doğru bilgi kaynağı olduğunu açıklar. Bu yazı ise Git'e geçtikten sonra kalan işbirliği boşluğunu ve Apidog gibi araçların spesifikasyonu Git'ten çıkarmadan bu boşluğu nasıl kapatabileceğini gösterir.

Git'in tek başına kapatamadığı boşluk

Git; değişiklik geçmişi, dallanma ve PR diff'leri için güçlüdür. Ancak OpenAPI spesifikasyonu tüm ekip tarafından kullanılan ortak bir sözleşmeye dönüştüğünde bazı ihtiyaçlar Git'in doğal kapsamı dışında kalır.

1. Tasarım aşamasında yorum yapmak zorlaşır

Bir QA mühendisi openapi.yaml içinde tutarsız bir hata şeması gördüğünde, GitHub PR diff'inde 247. satıra yorum bırakabilir. Ancak bu deneyim, spesifikasyonu belge olarak okuyan kişiler için doğal değildir.

Daha kullanışlı akış şudur:

QA, belge görünümünde POST /payments uç noktasını açar.
Eksik idempotency-key başlığını doğrudan uç nokta üzerinde işaretler.
Geliştirici YAML dosyasını günceller.
Yorum satır numarasına değil, API öğesine bağlı kalır.

2. Ön uç ekipleri dala özel mock ister

Ön uç geliştiricileri, arka uç uygulaması tamamlanmadan önce çalışan bir mock sunucusuna ihtiyaç duyar. Git'teki ham YAML dosyası bunu tek başına sağlamaz.

Örneğin:

npx @stoplight/prism-cli mock openapi.yaml

Bu komut çalışır; ancak manuel bir adımdır. Her branch için ayrı mock URL üretmek, bunu ekip akışına bağlamak ve güncel tutmak ek bir katman gerektirir.

3. Bildirimler role göre yönlendirilmelidir

Bir ekip /payments yanıt şemasında bozucu bir değişiklik yaptığında yalnızca "dosya değişti" bildirimi yeterli değildir.

Daha faydalı bildirim şuna benzer:

/payments yanıt şeması değişti.
Etkilenen ekipler: frontend, mobile, QA
Branch: feature/payment-v2

Git webhook'ları Slack'e genel bildirim gönderebilir. Ancak uç nokta, etiket veya tüketici bazlı yönlendirme için API odaklı bir işbirliği katmanı gerekir.

4. Belge erişimi hedef kitleye göre yönetilmelidir

Genel bir GitHub deposundaki spesifikasyon herkes tarafından okunabilir. Özel depo bunu çözer; ancak harici bir iş ortağının yalnızca belirli uç noktaları görebilmesi, Git'in doğal olarak sunduğu bir yetenek değildir.

Örneğin:

Partner: /payments, /refunds
Dahili ekip: /admin, /internal
QA: tüm staging uç noktaları

Bu model için belge katmanında erişim kontrolü gerekir.

İşbirliği katmanı ne yapmalı?

Pratik model şu olmalıdır:

Git = doğruluk kaynağı
İşbirliği katmanı = belge + yorum + mock + bildirim + CI/CD bağlantısı

Yani araç, OpenAPI dosyasını kendi içinde ayrı bir kopyaya dönüştürmek yerine Git'teki dosyadan okumalı ve onun üzerine ekip iş akışını bağlamalıdır.

Kategori	Örnekler	Güçlü yönler	Git'in üzerine ekledikleri
Barındırılan spesifikasyon platformları	Stoplight, SwaggerHub	Kullanıcı arayüzü, yorumlar, erişim kontrolü	Genellikle spesifikasyonun kendi kopyasını tutar; Git isteğe bağlıdır
Dosya tabanlı işbirliği katmanları	Apidog Spec-First Modu, Redocly	Git'teki dosyadan çalışır	Belge, mock, inceleme ve CI katmanı ekler
Git yerel API istemcileri	Bruno, Insomnia	Dosya senkronizasyonu, kod olarak koleksiyonlar	Genellikle istek katmanında kalır

Araç seçerken tek bir özelliğe bakmak yerine şu soruları sorun:

Git tek doğruluk kaynağı olarak kalıyor mu?
Yorumlar YAML satırına mı, API öğesine mi bağlı?
Her branch için mock üretilebiliyor mu?
CI içinde sözleşme testi çalıştırılabiliyor mu?
Belge erişimi role göre yönetilebiliyor mu?

Bruno nerede güçlü, nerede sınırlı?

Bruno, dosya tabanlı API koleksiyonları ve Git entegrasyonu konusunda güçlüdür. Bruno Ultimate; dosya tabanlı koleksiyon depolama, Git entegrasyonu, SSO, SCIM, sır yöneticisi bağlantıları ve denetim günlüğü gibi özellikler sunar.

Eğer temel ihtiyacınız şuysa Bruno iyi bir seçenek olabilir:

Git'te duran koleksiyonları senkronize et
İstekleri çalıştır
Ortamları yönet

Ancak Bruno'nun doğal sınırı istek katmanıdır. Kaydedilmiş OpenAPI dosyasından otomatik belge üretmek, branch bazlı mock sunucuları oluşturmak veya spesifikasyon değişikliklerine göre role özel bildirim göndermek için ek araç gerekir.

Bu nedenle, zaten Stoplight ile belge ve mock yönetiyorsanız Bruno'yu eklemek Stoplight'ın yerini almak değil, yanına yeni bir araç eklemek anlamına gelir.

Apidog Spec-First Modu nasıl çalışır?

Apidog'un Spec-First Modu şu mimari için tasarlanmıştır:

openapi.yaml Git'te kalır
Apidog dosyayı okur
Belge, yorum, mock, test ve bildirim katmanı eklenir

Apidog burada spesifikasyonu kendi veritabanına çatallayan ana kaynak gibi davranmaz. Yetkili kaynak Git'teki dosyadır.

Uygulama adımları

Adım 1: Git deponuzu bağlayın

Apidog'da bir projeyi GitHub, GitLab veya Bitbucket deposuna bağlayın ve OpenAPI dosya yolunu belirtin.

Örnek depo yapısı:

repo/
  api/
    openapi.yaml
  src/
  .github/
    workflows/

Örnek OpenAPI dosyası:

# api/openapi.yaml
openapi: "3.1.0"
info:
  title: Payments API
  version: "2.4.0"

paths:
  /payments:
    post:
      summary: Create a payment
      operationId: createPayment
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/PaymentRequest"
      responses:
        "201":
          description: Payment created
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/PaymentResponse"
        "422":
          description: Validation error
          content:
            application/json:
              schema:
                $ref: "#/components/schemas/ValidationError"

components:
  schemas:
    PaymentRequest:
      type: object
      required: [amount, currency, source]
      properties:
        amount:
          type: integer
          description: Amount in smallest currency unit, for example cents
        currency:
          type: string
          enum: [usd, eur, gbp]
        source:
          type: string
          description: Payment method token

    PaymentResponse:
      type: object
      properties:
        id:
          type: string
        status:
          type: string
          enum: [pending, completed, failed]

    ValidationError:
      type: object
      properties:
        code:
          type: string
        message:
          type: string

Bağlantı adımları için apidog-git-integration-sync rehberine bakabilirsiniz.

Adım 2: Diff yerine API öğesi üzerinden inceleme yapın

Depo bağlandıktan sonra Apidog, OpenAPI dosyasını etkileşimli belge olarak gösterir. Ekip üyeleri doğrudan şunlara yorum bırakabilir:

Uç noktalar
Request body şemaları
Response şemaları
Örnek yanıtlar
Header tanımları

Örneğin QA şu yorumu POST /payments üzerinde açabilir:

Bu uç nokta için idempotency-key header'ı zorunlu olmalı mı?
Tekrarlı ödeme riskini nasıl engelliyoruz?

Geliştirici daha sonra YAML dosyasını güncelleyip commit gönderir:

paths:
  /payments:
    post:
      parameters:
        - name: idempotency-key
          in: header
          required: true
          schema:
            type: string
          description: Prevents duplicate payment creation

Yorum, satır numarasına değil API öğesine bağlı kaldığı için değişiklik sonrası bağlam kaybolmaz.

Adım 3: Branch bazlı mock oluşturun

Spec-First Modu ile her branch, kendi OpenAPI durumuna göre ayrı mock üretebilir.

Örnek akış:

main                  -> production mock
feature/payment-v2    -> payment v2 mock
fix/validation-error  -> validation fix mock

Bu, ön uç geliştirme için özellikle kullanışlıdır:

Backend ekibi feature/payment-v2 branch'inde OpenAPI şemasını günceller.
Apidog bu branch'e bağlı mock üretir.
Frontend ekibi yeni mock URL ile entegrasyona başlar.
Backend tamamlanmadan UI geliştirme ilerler.

Adım 4: Bildirimleri doğru ekibe gönderin

Spesifikasyonda bir yol veya şema değiştiğinde bildirimleri uç nokta, etiket veya yol ön ekine göre yönlendirmek daha kullanışlıdır.

Örnek yönlendirme modeli:

/payments/**  -> #payments-frontend, #mobile
/admin/**     -> #internal-backend
/refunds/**   -> #finance-qa

Slack için Slack gelen webhook'ları, Teams için Microsoft Teams gelen webhook'ları belgelerine bakabilirsiniz.

Deneme sırasında özellikle şunları doğrulayın:

Bildirimler etiket bazında mı, yol bazında mı yönlendirilebiliyor?
Bozucu değişiklikler ayrı işaretlenebiliyor mu?
Belge hedef kitleleri kuruluş rollerinizle eşleşiyor mu?

CI/CD ile sözleşme testi ekleyin

İşbirliği katmanı yalnızca belge ve yorum için değil, CI/CD için de kullanılmalıdır.

Temel hedef:

OpenAPI dosyası geçerli mi?
API uygulaması bu sözleşmeye uyuyor mu?
Değişiklikler PR sırasında yakalanıyor mu?

Bunun için linting ve sözleşme testini aynı pipeline içinde çalıştırabilirsiniz.

# .github/workflows/api-spec.yml
name: API spec validation and test

on: [push, pull_request]

jobs:
  validate-and-test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Validate OpenAPI spec with Spectral
        run: |
          npm install -g @stoplight/spectral-cli
          spectral lint api/openapi.yaml --ruleset .spectral.yaml

      - name: Run Apidog contract tests
        env:
          APIDOG_TOKEN: ${{ secrets.APIDOG_TOKEN }}
        run: |
          npx apidog-cli run \
            --project-id ${{ vars.APIDOG_PROJECT_ID }} \
            --test-suite "Payments API smoke" \
            --environment staging

OpenAPI spesifikasyonu, API'nizin ne vaat ettiğini tanımlar. CI içinde sözleşme testi çalıştırmak, yalnızca birim testleri değil, çalışan servisin bu sözleşmeden sapıp sapmadığını da kontrol eder.

Linting için Spectral veya Redocly CLI kullanabilirsiniz. Git-yerel uçtan uca akış için git-native-api-workflow yazısına bakabilirsiniz.

Dosya tabanlı ekipler için karşılaştırma

Aşağıdaki tablo, OpenAPI dosyasını Git'te tutmak isteyen ekipler için temel değerlendirme başlıklarını özetler. Soru işaretiyle belirtilen yetenekleri kendi denemenizde doğrulamanız gerekir; plan ve yapılandırmaya göre değişebilir.

Yetenek	Stoplight	SwaggerHub	Apidog Spec-First, beta
Git'in yetkili kaynak olması	İsteğe bağlı; varsayılan olarak kendi kopyası	İsteğe bağlı	Evet
Tasarım aşaması yorumları	Evet	Evet	Evet
Branch bazlı mock	Evet	Kısmi	Evet
Role dayalı belge erişimi	Evet	Evet	Denemede kontrol edin
Projeler arası şema yeniden kullanımı	Evet	Evet	Denemede kontrol edin
CI/CD sözleşme testi	Prism aracılığıyla	Sınırlı	Evet, Apidog CLI ile
Özel lint kuralları	Spectral aracılığıyla	Sınırlı	Denemede kontrol edin
SSO/SCIM	Ücretli katmanlar	Kurumsal	Denemede kontrol edin
Bildirim yönlendirme	Webhook'lar aracılığıyla	Sınırlı	Evet
Çift kopya olmadan dosya tabanlı çalışma	Hayır	Hayır	Evet, Spec-First ile

SwaggerHub karşılaştırması için swaggerhub-vs-apidog-collaboration yazısına bakabilirsiniz.

Sıkça sorulan sorular

Git PR incelemelerini Apidog yorumlarıyla birlikte kullanabilir miyiz?

Evet. İki akış farklı kitlelere hizmet eder.

Git PR incelemeleri: YAML değişikliğini inceleyen mühendisler
Apidog yorumları: spesifikasyonu belge olarak inceleyen QA, ürün ve ön uç ekipleri

Kaydedilmiş OpenAPI dosyası her iki akış için de tek doğruluk kaynağı olarak kalır.

Biri spesifikasyonu Apidog arayüzünde düzenlerse ne olur?

Spec-First Modu'nda Apidog arayüzündeki düzenlemeler Git'e commit olarak gönderilebilir. Tipik akış şöyledir:

UI'da düzenle
Branch'e commit et
Git'te PR aç
PR incelemesini tamamla
Merge et

Bu akışı kendi denemenizde doğrulamanız önemlidir. Özellikle düzenlemelerin nereden başlayacağına karar vermelisiniz:

Yalnızca Git'ten Apidog'a mı?
Apidog'dan Git'e commit de olacak mı?
PR zorunlu mu?

Adım adım inceleme için spec-first-mode-apidog-beta-walkthrough yazısına bakabilirsiniz.

Spec-First Modu monorepo içinde çalışır mı?

Birden fazla OpenAPI dosyası olan monorepo yapıları yaygındır.

Örnek:

repo/
  services/
    payments/
      openapi.yaml
    identity/
      openapi.yaml
    notifications/
      openapi.yaml

Apidog, farklı dosya yollarına bağlı birden fazla projeyi destekler. Ancak tek bir Apidog projesinin birden fazla OpenAPI dosyasına eşlenip eşlenemeyeceğini veya lint kurallarının projeler arasında nasıl paylaşılacağını kendi depo yapınızla test etmeniz gerekir.

Redocly ile nasıl karşılaştırılır?

Redocly CLI, OpenAPI linting, bundling ve dosyalardan belge üretme konusunda güçlüdür. Redocly'nin barındırılan platformu ekip özellikleri ve inceleme katmanı ekler.

Fark şudur:

Redocly CLI, dosya tabanlı otomasyon için güçlüdür.
Redocly platformu, işbirliği özelliklerini barındırılan katmanda sunar.
Apidog, Git'teki dosyadan okuyan tek bir platformda belge, mock, sözleşme testi ve bildirimleri birleştirmeyi hedefler.

OpenAPI Girişimi'nin araçları bu problemi çözer mi?

OpenAPI Girişimi, spesifikasyonun kendisini yayınlar; işbirliği platformu yayınlamaz. Seçtiğiniz araç, OpenAPI spesifikasyonunu uygulayan ekosistemin parçasıdır.

Eğer OpenAPI 3.1 kullanıyorsanız, seçtiğiniz aracı mutlaka OpenAPI 3.1 desteği açısından test edin. 3.1 desteği araçlar arasında farklılık gösterebilir.

Sonuç

OpenAPI dosyanız Git'teyse sürümleme problemi büyük ölçüde çözülmüştür. Ancak ekip işbirliği problemi hâlâ devam eder.

Pratikte ihtiyacınız olan katman şunları sağlamalıdır:

Mühendis olmayan ekipler için API öğesi bazlı yorumlar
Ön uç ekipleri için branch bazlı mock'lar
Bozucu değişiklikler için role özel bildirimler
Hedef kitleye göre erişim kontrollü belgeler
CI/CD içinde linting ve sözleşme testi

Bu katmanın Git'in yerini alması gerekmez. Git'ten okumalı, onun üzerine inşa edilmeli ve mühendislerin PR tabanlı kod inceleme akışını bozmamalıdır.

Mevcut kurulumunuzda Git sürümlemeyi, Stoplight veya benzeri bir araç belge işbirliğini sağlıyorsa, Apidog Spec-First Modu bu iki tarafı birleştirmek için tasarlanmıştır. Beta aşamasında olduğu için özellikle belge erişim kontrolü, şema yeniden kullanımı ve bildirim ayrıntı düzeyi gibi ihtiyaçları kendi ekibinizin akışıyla test edin.

Apidog'u indirin ve mevcut OpenAPI deponuzun bir branch'ine bağlayarak işbirliği katmanının Git tabanlı akışınıza nasıl uyduğunu deneyin.

Postman Koleksiyonları Neden Tek Doğruluk Kaynağı Değil (ve Çözümleri)

Tobias Hoffmann — Fri, 05 Jun 2026 06:59:49 +0000

Postman koleksiyonları ile OpenAPI belirtimi arasındaki fark, ekip büyüdükçe kritik hale gelir. Altı ay önce oluşturduğunuz bir koleksiyon; artık üç yeni zorunlu alanı, iki kullanım dışı parametreyi ve gerçek sunucu yanıtıyla uyuşmayan bir response yapısını temsil ediyor olabilir. Bu sırada Git'teki OpenAPI belirtimi başka bir şey, Swagger UI başka bir şey söylüyorsa sorun araçta değil, iş akışındadır.

Apidog'u bugün deneyin

Postman; istek çalıştırma, betikleme ve keşif testi için güçlüdür. Ancak koleksiyonu API sözleşmesinin kendisi gibi kullanmak, zamanla sapma üretir. Daha sürdürülebilir model şudur: OpenAPI belirtimi kaynak olur, Postman koleksiyonu bu belirtimden üretilen bir çıktı olur.

💡 Bu bağımlılığı tersine çevirdiğinizde sapma azalır. Apidog, belirtim odaklı iş akışını işbirliği, mock, test ve CI/CD ile bağlayarak ekibin aynı API kaynağı üzerinden çalışmasına yardımcı olur. Mevcut Postman çalışmalarınızı çöpe atmadan bu modele geçebilirsiniz.

Koleksiyonlar neden sapar?

Postman koleksiyonu istek odaklıdır:

Bir endpoint çağırırsınız.
Yanıtı gözlemlersiniz.
İsteği kaydedersiniz.
Zamanla değişkenler, pre-request script'ler, test assertion'ları ve klasör yapıları eklersiniz.

Bu yapı, API'nin resmi sözleşmesinden çok ekibin API'yi nasıl çağırdığını gösterir.

OpenAPI belirtimi ise sözleşme odaklıdır. Endpoint'leri, parametreleri, şemaları ve yanıtları makine tarafından okunabilir şekilde tanımlar. Araçlar bu dosyadan doğrulama, mock, dokümantasyon ve kod üretimi yapabilir.

İki yapı farklı sorulara cevap verir:

Postman koleksiyonu: “Bu endpoint'i bugün nasıl çağırırım?”
OpenAPI belirtimi: “Bu API ne yapmalı?”

Sorun, ekipler bu iki dosyayı bağımsız güncellediğinde başlar. Bir geliştirici PR içinde OpenAPI dosyasını değiştirir. Başka biri bozulan testi düzeltmek için koleksiyonu günceller. İki değişiklik birleşmez. Birkaç ay sonra aynı API'nin iki kısmen doğru açıklaması oluşur.

Inventis Korea'nın yaşadığı sorun da buydu: ekip API oluşturuyor, Swagger için OpenAPI belirtimi üretiyor, test için koleksiyonu Postman'e aktarıyor ve ardından üç temsili senkron tutmaya çalışıyordu. Koleksiyon tam şemayı yansıtmadığı için testler bazı edge case'leri kaçırıyordu. Belirtim testlerin girdisi olmadığı için dokümantasyon sapıyordu.

Temel neden: Postman bir belirtim deposu değildir

Postman koleksiyonlarının kendi formatı vardır. Postman koleksiyon şeması, istekleri, script'leri ve klasör hiyerarşilerini tanımlayan JSON tabanlı bir formattır. OpenAPI değildir.

Postman OpenAPI içe ve dışa aktarabilir, ancak bu dönüşüm her zaman birebir değildir:

OpenAPI → Postman dönüşümünde şema ayrıntılarının bir kısmı koleksiyonda temsil edilemeyebilir.
Postman → OpenAPI dönüşümünde script'ler, testler ve runtime verileri belirtime aktarılamayabilir.

Bu Postman'in zayıflığı değil, tasarım sınırıdır. Postman istek yürütme merkezlidir; OpenAPI ise sözleşme tanımı merkezlidir.

Özellik	Postman koleksiyonu	OpenAPI belirtimi
İstek parametreleri	Anahtar-değer çiftleri olarak tutulur	Tür, `required`, `schema` ve doğrulama bilgileriyle tanımlanır
Yanıt yapısı	Opsiyonel örnek olarak saklanır	JSON Schema ile tanımlanır
Hata yanıtları	Her isteğe manuel eklenir	`responses` altında standartlaştırılır
Şema yeniden kullanımı	Genellikle kopyala-yapıştır	`components/schemas` ve `$ref` ile yapılır
Makine tarafından okunabilir sözleşme	Sınırlı	Evet
Git diff uygunluğu	Opak JSON nedeniyle zor	YAML/JSON üzerinde anlamlı diff alınabilir
Lint ve doğrulama	Yerel koleksiyon formatında sınırlı	Spectral, Redocly CLI vb. ile yapılabilir

Sonuç: koleksiyon sözleşmeyi tam ifade edemediği için gerçek sözleşme başka yerde yaşar. Bir dosya güncellenip diğeri güncellenmediğinde sapma başlar.

Belirtim odaklı yaklaşım nedir?

Belirtim odaklı yaklaşım, “önce aylarca YAML yazın, sonra kodlayın” demek değildir. Pratik anlamı şudur:

OpenAPI belirtimi Git'te API'nin yetkili kaynağı olur.
Dokümantasyon, mock'lar, testler ve koleksiyonlar bu belirtimden üretilir.
API değişikliği önce belirtimde yapılır.
Aşağı akış çıktıları otomatik veya araçlar aracılığıyla güncellenir.

Belirtim odaklı metodoloji, Postman koleksiyonunu kaldırmak zorunda değildir. Sadece koleksiyonun yönünü değiştirir: koleksiyon artık kaynak değil, çıktıdır.

Pratik akış:

openapi.yaml Git'e kaydedilir.
PR içinde gözden geçirilir.
CI içinde lint edilir.
Mock, dokümantasyon ve test koleksiyonu belirtimden oluşturulur.
Testler oluşturulan koleksiyona karşı çalışır.

Bu modelde Postman hâlâ kullanılabilir. Pre-request script'leriniz, environment değişkenleriniz ve keşif testleriniz devam eder. Fark şudur: request yapısı manuel tutulan bir koleksiyondan değil, OpenAPI belirtiminden gelir.

OpenAPI belirtiminden Postman koleksiyonu üretme

Bir OpenAPI dosyasından Postman uyumlu koleksiyon üretmek için Redocly CLI ve openapi-to-postmanv2 kullanabilirsiniz.

# Redocly CLI'yi yükleyin
npm install -g @redocly/cli

# OpenAPI belirtimini doğrulayın
redocly lint openapi/petstore.yaml

# $ref zincirlerini çözerek tek dosya üretin
redocly bundle openapi/petstore.yaml -o dist/petstore-bundled.yaml

# Postman Collection v2.1 formatına dönüştürün
npm install -g openapi-to-postmanv2

openapi2postmanv2 \
  --spec dist/petstore-bundled.yaml \
  --output dist/petstore-collection.json \
  --prettyPrint

Çıktı standart bir Postman koleksiyonu JSON dosyasıdır:

dist/petstore-collection.json

Bunu şu şekilde kullanabilirsiniz:

Postman'e import edebilirsiniz.
Newman ile CI içinde çalıştırabilirsiniz.
Postman CLI için temel koleksiyon olarak kullanabilirsiniz.

Önemli nokta: koleksiyonu elle düzenlemek yerine her çalıştırmada belirtimden yeniden üretirsiniz.

CI içinde koleksiyonu otomatik üretme

Aşağıdaki GitHub Actions örneği, her API değişikliğinde belirtimi lint eder, koleksiyonu üretir ve Newman ile testleri çalıştırır.

# .github/workflows/api-tests.yml
name: API sözleşme testleri

on:
  push:
    paths:
      - "openapi/**"
      - "src/**"

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - name: Bağımlılıkları yükle
        run: |
          npm install -g @redocly/cli openapi-to-postmanv2 newman

      - name: OpenAPI belirtimini doğrula
        run: redocly lint openapi/petstore.yaml

      - name: Belirtimden koleksiyon oluştur
        run: |
          mkdir -p dist
          redocly bundle openapi/petstore.yaml -o dist/petstore-bundled.yaml
          openapi2postmanv2 \
            --spec dist/petstore-bundled.yaml \
            --output dist/petstore-collection.json \
            --prettyPrint

      - name: Oluşturulan koleksiyona karşı testleri çalıştır
        run: |
          newman run dist/petstore-collection.json \
            --environment config/env-staging.json \
            --reporters cli,junit \
            --reporter-junit-export results/test-results.xml

      - name: Test sonuçlarını yükle
        uses: actions/upload-artifact@v4
        with:
          name: test-results
          path: results/

Bu kurulumla belirtim her test çalıştırmasının girdisi olur. Bir PR belirtimi bozarsa, sorun aynı PR içinde yakalanır.

Apidog bu iş akışına nasıl uyuyor?

Apidog'un amacı Postman'i sadece bir istek yürütücü olarak değiştirmek değildir. Asıl değer, OpenAPI belirtimini işbirliği, mock, dokümantasyon ve test katmanlarıyla bağlamasıdır.

Apidog'un Belirtim Odaklı Modu şu anda beta aşamasındadır. Bu mod ile bir OpenAPI belirtimini Git deposundan Apidog çalışma alanına senkronize edebilirsiniz.

Bu senkronize belirtimden şunlar üretilebilir:

Otomatik mock'lar
Etkileşimli API dokümantasyonu
Test senaryoları
Ekip içinde ortak çalışma yüzeyleri

Belirtim Git'te değiştiğinde Apidog tarafındaki yüzeyler de aynı kaynağa göre güncellenir. Böylece ayrı bir koleksiyon, ayrı bir dokümantasyon aracı ve ayrı bir mock sunucusunu manuel senkron tutma ihtiyacı azalır.

STC Group ve Dünya Ekonomik Forumu'nun açıkladığı gibi ekipler genellikle üç ayrı sistemle çalışır:

Test için Postman
Belirtim/dokümantasyon için ayrı araç
Frontend geliştirme için mock sunucusu

Belirtim odaklı modelde bu üç yüzey aynı OpenAPI kaynağından beslenir.

Büyük ekiplerde, özellikle DHL dağıtımında görülen 100+ kullanıcı gibi senaryolarda, Apidog'un çalışma alanı izinleri ve SSO özelliklerinin ihtiyaçlarınıza uyup uymadığını deneme sırasında doğrulamak gerekir. Bu, üretime almadan önce yapılması gereken makul bir POC adımıdır.

Mevcut Postman koleksiyonlarınız varsa, başlangıç noktası olarak Apidog'a dönüştürebilir ve ardından belirtimi ileriye dönük standart kaynak yapabilirsiniz.

OpenAPI belirtimini Git'te kod gibi yönetin

API belirtimi-kod olarak yaklaşımı, OpenAPI dosyasının uygulama kodu gibi yönetilmesi anlamına gelir:

Pull request
Code review
CI lint
Sürüm etiketi
Branch stratejisi

Başlamak için uygulanabilir adımlar:

1. Belirtimi servis reposunda tutun

Belirtimi ayrı bir “docs” reposuna koymak yerine, tanımladığı servisle aynı repoda saklayın.

Örnek yapı:

service-a/
  src/
  openapi/
    openapi.yaml
  .github/
    workflows/
      api-tests.yml

Böylece API davranışı ve API sözleşmesi aynı PR içinde değişir.

2. CI içine Spectral ekleyin

Spectral, OpenAPI dosyanızı OpenAPI belirtimine ve özel kurallarınıza göre doğrular.

Basit kurulum:

npm install -g @stoplight/spectral-cli
spectral lint openapi/openapi.yaml

GitHub Actions adımı:

- name: OpenAPI lint
  run: |
    npm install -g @stoplight/spectral-cli
    spectral lint openapi/openapi.yaml

Bu sayede şu problemler review yorumuna kalmadan CI hatasına dönüşür:

Bozuk $ref
Eksik response tanımı
Tutarsız endpoint adlandırması
Eksik açıklamalar
Geçersiz schema yapıları

3. Bozucu değişiklikler için branch kullanın

Breaking change içeren API değişikliklerini doğrudan ana dala göndermeyin. Uygulama kodunda yaptığınız gibi belirtim için de branch kullanın.

Örnek:

main
feature/add-billing-v2
breaking/remove-legacy-customer-field

Apidog çalışma alanları belirtim üzerinde dallanmayı destekler. Böylece bir ekip kararlı branch ile çalışırken başka bir ekip bozucu değişikliği inceleyebilir.

4. Tüketici servislerde belirtim sürümünü sabitleyin

Servis B, Servis A'nın sözleşme testlerine bağımlıysa main branch'in son haline değil, belirli bir sürüm etiketine bağlanmalıdır.

Örnek:

service-a-openapi@v1.8.0

Bu, tüketici testlerinin beklenmedik şekilde kırılmasını önler.

Daha ayrıntılı kurulum için Git-yerel API iş akışı kılavuzuna bakabilirsiniz.

Sıkça Sorulan Sorular

Postman'i tamamen bırakmak zorunda mıyım?

Hayır. Değişiklik araçtan çok bağımlılık yönüyle ilgilidir. Postman'i keşif testi, manuel deneme ve script tabanlı akışlar için kullanmaya devam edebilirsiniz.

Fark şu olur: koleksiyonu manuel sürdürülen bir kaynak olarak değil, OpenAPI belirtiminden üretilen bir çıktı olarak ele alırsınız.

Mevcut Postman script'leri ve environment değişkenleri ne olur?

Pre-request script'ler, test script'leri ve environment değişkenleri ayrı dosyalar olarak korunabilir. Koleksiyonu belirtimden yeniden oluştururken bu davranışsal katmanı ayrı yönetirsiniz.

Önerilen ayrım:

openapi/
  openapi.yaml

postman/
  env-staging.json
  env-prod.json
  scripts/

Yapısal katman OpenAPI'den gelir. Runtime davranışı ayrı tutulur.

Henüz belirtimde olmayan endpoint'leri nasıl ele alırım?

Belirtim odaklı iş akışında belirtimde olmayan endpoint test için hazır değildir. Bu bilinçli bir kapıdır.

Önerilen akış:

Yeni endpoint için OpenAPI girdisini ekleyin.
PR içinde schema, request ve response tanımlarını inceletin.
Mock veya stub ile frontend/backend paralel geliştirme yapın.
Test koleksiyonunu belirtimden üretin.

Belirtim düzenleme ve doğrulama araçları için en iyi OpenAPI doğrulayıcı araçları kılavuzuna bakabilirsiniz.

Apidog Belirtim Odaklı Modu kullanılabilir mi?

Apidog Belirtim Odaklı Modu şu anda beta aşamasındadır. Apidog üzerinden erişebilir ve Git senkronizasyonu, branch desteği ve otomatik mock özelliklerini kendi API yapınızla test edebilirsiniz.

Beta özelliklerde olduğu gibi, üretim iş akışına almadan önce gerçek belirtiminizle POC yapmanız önerilir.

Belirtimi Postman'e import etmekten farkı ne?

Postman'e OpenAPI import etmek tek seferlik dönüşümdür. Import sonrası koleksiyon belirtimden bağımsız yaşamaya başlar ve sapma tekrar oluşur.

Belirtim odaklı modelde koleksiyon her CI çalıştırmasında veya senkronizasyonda yeniden oluşturulur. Böylece koleksiyon, belirtimden en fazla bir build kadar geride kalır.

Sonuç

Postman koleksiyonu ile OpenAPI belirtimi arasındaki sapma Postman hatası değildir. Sorun, iki kısmen çakışan API açıklamasını net bir kaynak ilişkisi olmadan sürdürmektir.

Daha sağlam model:

OpenAPI belirtimini Git'te yetkili kaynak yapın.
Belirtimi PR ve CI süreçlerine dahil edin.
Postman koleksiyonunu belirtimden üretin.
Test, mock ve dokümantasyonu aynı kaynaktan besleyin.

Bu tersine çevirme bakım yükünü azaltır. Testleri bozan belirtim değişiklikleri aynı PR içinde yakalanır. Dokümantasyon, mock'lar ve test senaryoları aynı sözleşmeye bağlı kalır.

Apidog'u indirin ve mevcut OpenAPI belirtiminizle Belirtim Odaklı Mod çalışma alanı açın. Eğer başlangıç noktanız bir Postman koleksiyonuysa, koleksiyonu OpenAPI'ye geçiş için ara adım olarak kullanabilir ve sonrasında belirtim odaklı iş akışına geçebilirsiniz.

Swagger ve Postman Koleksiyonları Arasındaki Senkronizasyon Sorunları (ve Çözümleri)

Tobias Hoffmann — Fri, 05 Jun 2026 06:31:17 +0000

Swagger Postman kayması bir süreç hatası değildir. Aynı API sözleşmesini, onları senkronize tutacak hiçbir mekanizma olmadan iki ayrı yerde sakladığınızda ortaya çıkar. Bir openapi.yaml yazarsınız, Swagger UI belgeleri buradan üretir, sonra testler için bir Postman koleksiyonu dışa aktarırsınız. Bir hafta sonra biri koleksiyonda bir uç noktayı değiştirir, YAML aynı kalır ve artık belgeler ile testler farklı API'leri tarif eder. Bir spesifikasyondan test oluşturma adımları için OpenAPI test üretimi kılavuzuna bakabilirsiniz.

Apidog'u bugün deneyin

💡 Apidog kullanan ekipler, OpenAPI dosyasını belgeleri, mock sunucuları ve testleri yönlendiren tek yapıt olarak ele alır. Yapısal çözüm daha sıkı manuel inceleme değil, kaymaya neden olan ikinci sözleşme kopyasını ortadan kaldırmaktır.

İki dosya neden her zaman birbirinden uzaklaşır?

Tipik kurulum şudur:

Depoda bir openapi.yaml vardır.
Test ekibi veya backend geliştiricileri ayrıca bir Postman koleksiyonu tutar.
Swagger UI yalnızca YAML'den belge üretir.
Postman koleksiyonu ayrı bir çalışma alanında değişir.

Bu iki yapıt aynı API sözleşmesini temsil eder, ancak birbirlerini doğrulamaz.

Örnek senaryo:

Backend ekibi yeni bir POST /payments/refund uç noktası yayınlar.
Yeni istek gövdesinde zorunlu reason alanı vardır.
QA, testleri çalıştırmak için uç noktayı Postman koleksiyonuna ekler.
openapi.yaml güncellemesi sonraki sprint'e kalır.
Frontend geliştirici Swagger belgesine bakarak endpoint'i reason olmadan çağırır.
API 400 döner, ancak Swagger belgesi hatayı açıklamaz.

Sorun ihmal değildir. Sorun, iki ayrı sözleşme kopyasının hiçbir bağlayıcı mekanizma olmadan yaşamasıdır.

Yapıt	Kim günceller	Güncelleme tetikleyicisi	Doğrulama
`openapi.yaml`	API tasarımcısı / teknik lider	Planlanmış belge sprint'i	İsteğe bağlı linter, örn. Spectral
Postman koleksiyonu	QA / backend geliştirici	Test gerektiğinde	Manuel inceleme veya yok
Swagger UI görünümü	YAML'den otomatik oluşturulur	Sadece YAML değiştiğinde	YAML'yi yansıtır, gerçek API'yi değil

YAML için Spectral gibi bir linter çalıştırmak faydalıdır. Ancak linter yalnızca spesifikasyon içindeki sorunları yakalar. YAML ile Postman koleksiyonu arasındaki farkı yakalamaz.

Üç kopya problemi

Stoplight, Swagger UI veya wiki tabanlı ayrı bir dokümantasyon katmanı kullanıyorsanız problem büyür. Artık sözleşmenin üç kopyası vardır:

Git'e işlenmiş openapi.yaml
Dışa aktarılmış Postman koleksiyonu
Stoplight, Swagger UI veya wiki üzerinde oluşturulan dokümantasyon

Her kopya bağımsız olarak kayabilir.

OpenAPI Spesifikasyonu bir açıklama formatıdır. Çalışma zamanında API davranışını zorlamaz ve Postman koleksiyonunuzun aynı sözleşmeye uyduğunu garanti etmez.

Bu nedenle ekip büyüdükçe bakım maliyeti artar:

Daha fazla servis
Daha fazla endpoint
Daha fazla test koleksiyonu
Daha fazla manuel senkronizasyon
Daha fazla kayma riski

Kayma testleri nasıl sessizce bozar?

Swagger Postman kaymasının en tehlikeli tarafı şudur: testler yanlış olsa bile geçmeye devam edebilir.

Örneğin güncel OpenAPI spesifikasyonunuz şöyle olsun:

# openapi.yaml - güncellenmiş spesifikasyon (v2)
paths:
  /payments/refund:
    post:
      summary: Geri ödeme başlat
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              required:
                - transaction_id
                - reason          # v2'de eklenen yeni zorunlu alan
              properties:
                transaction_id:
                  type: string
                  example: "txn_8x9Ka21"
                reason:
                  type: string
                  enum: [duplicate, fraudulent, requested_by_customer]
                  example: "requested_by_customer"
      responses:
        '200':
          description: Geri ödeme başlatıldı
          content:
            application/json:
              schema:
                type: object
                properties:
                  refund_id:
                    type: string
                  status:
                    type: string

Ama Postman koleksiyonunuz hâlâ v1 isteğini gönderiyor olabilir:

{
  "transaction_id": "txn_8x9Ka21"
}

Eğer backend geçiş dönemi için reason alanına varsayılan bir değer veriyorsa, Postman testi yeşil kalır. Fakat spesifikasyon artık reason alanını zorunlu kabul eder.

Sonuç:

Test geçer.
Spesifikasyon farklı bir sözleşme söyler.
Frontend entegrasyonu staging'de kırılabilir.
Kırılma, test çıktısından anlaşılmaz.

YAML'nize uygun bir OpenAPI doğrulayıcı çalıştırmak şema hatalarını yakalar. Ancak spesifikasyon ile Postman koleksiyonunun gerçekten gönderdiği istekler arasındaki farkı yakalamaz.

OpenAPI odaklı test ne anlama gelir?

OpenAPI odaklı testte spesifikasyon yetkili kaynaktır.

Yani:

Testler spesifikasyondan türetilir.
Belgeler spesifikasyondan türetilir.
Mock sunucu spesifikasyondan türetilir.
Ayrı bir sözleşme kopyası tutulmaz.

Bu, “Swagger'ı Postman'a aktarmak” ile aynı şey değildir.

Aktarım tek seferlik bir kopyalama işlemidir:

openapi.yaml dosyasını Postman'a aktarırsınız.
Bir koleksiyon oluşur.
Bu andan sonra YAML ve koleksiyon tekrar bağımsız hale gelir.
Sonraki her değişiklikte tekrar manuel aktarım gerekir.

Bu kaymayı çözmez; sadece sıfırlar.

Spesifikasyon-önce iş akışı ise şöyle çalışır:

openapi.yaml Git'te ana sözleşme olarak yaşar.
Araç bu dosyadan dokümantasyon, mock ve test üretir.
Pull request ile YAML değiştiğinde alt çıktılar da güncellenir.
Senkronize tutulacak ayrı bir Postman koleksiyonu kalmaz.

Spesifikasyon-önce API geliştirme modeli bu yaklaşımın daha geniş iş akışını açıklar. Buradaki odak, belgeler ve testler arasındaki kaymayı ortadan kaldırmaktır.

Apidog'u tek spesifikasyon üzerinde yürütme katmanı olarak kullanma

Apidog modeli şu varsayıma dayanır:

Git gerçeklik kaynağıdır.
openapi.yaml ana sözleşmedir.
Apidog bu sözleşme üzerinden dokümantasyon, mock ve test üretir.

Akış pratikte şöyle görünür:

openapi.yaml
    ├── Dokümantasyon
    ├── Mock sunucu
    └── Test paketi

Apidog'un Spesifikasyon-Önce Modu, bu iş akışı için tasarlanmıştır. OpenAPI dosyasını Apidog'a bağlarsınız; platform aynı dosyadan belgeleri, mock'ları ve testleri üretir. YAML değiştiğinde alt çıktılar da aynı kaynaktan güncellenir.

Bu modelde kayacak ayrı bir Postman koleksiyonu yoktur.

GitHub tabanlı ekipler için OpenAPI spesifikasyonunu GitHub ile senkronize etme iş akışı, spesifikasyonun GitHub'da nasıl tutulacağını ve Apidog ile nasıl uyumlu kalacağını gösterir.

POC sırasında özellikle şunları kontrol edin:

Mevcut OpenAPI şema karmaşıklığınız test üretiminde nasıl ele alınıyor?
Veri odaklı test senaryoları ihtiyacınızı karşılıyor mu?
Rapor görünürlüğü ve izinler kuruluş erişim modelinizle uyumlu mu?
Mock yanıtları frontend geliştirme akışınıza yeterli mi?

Mocking de aynı modelin parçasıdır. Mock, testlerle aynı spesifikasyondan türediğinde frontend geliştiricisi testlerin doğruladığı sözleşmeyle tutarlı yanıtlar alır. Detaylar için API mocking kullanım durumları bölümüne bakabilirsiniz.

Geçiş yolu: Swagger + Postman'dan tek spesifikasyona

Bu geçişi big-bang olarak yapmak zorunda değilsiniz. Daha güvenli yol kademeli ilerlemektir.

1. Mevcut farkı ölçün

Önce openapi.yaml ile Postman koleksiyonunu karşılaştırın.

Kontrol etmeniz gerekenler:

Koleksiyonda olup spesifikasyonda olmayan endpoint'ler
Spesifikasyonda olup koleksiyonda test edilmeyen endpoint'ler
Farklı HTTP metodları
Farklı path parametreleri
Farklı request body alanları
Farklı response şemaları

Basit bir başlangıç için endpoint listesini çıkarabilirsiniz:

# OpenAPI path listesini görmek için örnek
yq '.paths | keys' openapi.yaml

Postman koleksiyonunu JSON olarak dışa aktarıp endpoint'leri ayrı listeleyerek manuel karşılaştırma yapabilirsiniz.

2. Spesifikasyonu gerçek API ile uzlaştırın

openapi.yaml, ilk tasarlandığı API'yi değil, bugün çalışan API'yi tanımlamalıdır.

Bu adımda:

Eksik endpoint'leri ekleyin.
Artık kullanılmayan endpoint'leri kaldırın veya deprecated olarak işaretleyin.
Request body şemalarını güncelleyin.
Response örneklerini gerçek davranışla uyumlu hale getirin.
Zorunlu alanları gerçek doğrulama kurallarıyla eşleştirin.

3. Spesifikasyonu Apidog'a aktarın

Temizlenmiş openapi.yaml dosyasını Apidog'a aktarın. Apidog'un spesifikasyon yapısından başlangıç test paketini oluşturmasına izin verin.

Bu noktada hedef, mevcut Postman koleksiyonunu hemen silmek değildir. Önce aynı API'yi iki tarafta da çalıştırıp sonuçları karşılaştırın.

4. Bir sprint paralel çalıştırın

Bir sprint boyunca:

Mevcut Postman koleksiyonunu çalıştırın.
Apidog tarafında spesifikasyondan türetilen testleri çalıştırın.
Farklı sonuç veren endpoint'leri inceleyin.
Farkın kaynağını belirleyin: API mi yanlış, spesifikasyon mu yanlış, eski test mi yanlış?

5. Postman koleksiyonunu arşivleyin

Sonuçlar hizalandığında:

Postman koleksiyonunu regresyon kaynağı olarak kullanmayı bırakın.
Koleksiyonu salt okunur arşivleyin.
Git'teki openapi.yaml dosyasını tek sözleşme kaynağı yapın.
Test, mock ve dokümantasyonu spesifikasyondan türetin.

Spesifikasyondan ilk test koleksiyonunu üretme adımları için OpenAPI spesifikasyonlarından test koleksiyonları oluşturma kılavuzuna bakabilirsiniz.

Karşılaştırma: Çift bakım vs. kaynak olarak spesifikasyon

Boyut	Swagger + Postman	OpenAPI odaklı model
Kayma riski	Yüksek; iki yapıt ayrı güncellenir	Düşük; tek yapıt, türetilmiş çıktılar
Test kapsamı doğruluğu	Manuel senkronizasyona bağlı	Spesifikasyon değişikliklerini izler
Yeni geliştirici onboarding	İki araç ve iki sözleşme kopyası	Tek spesifikasyon
CI/CD entegrasyonu	Koleksiyon ayrıca dışa aktarılır ve sürümlenir	CI Git'teki spesifikasyonu okuyabilir
Mock tutarlılığı	Mock ayrıca yönetilir	Mock testlerle aynı spesifikasyondan türetilir
Şema değişikliği maliyeti	Spesifikasyonu, koleksiyonu ve mock'u ayrı güncelle	Spesifikasyonu bir kez güncelle

Bu, Postman'ın kötü bir araç olduğu anlamına gelmez. Postman koleksiyon tabanlı testlerde güçlüdür. Sorun, koleksiyonu türetilmiş bir çıktı yerine ikinci bir sözleşme kaynağı olarak kullanmaktır.

Sıkça Sorulan Sorular

Swagger'ı Postman'a aktarmak neden kaymayı çözmez?

Çünkü aktarım anlık bir kopya oluşturur. Aktarımdan sonra openapi.yaml ve Postman koleksiyonu bağımsız hale gelir. YAML'deki sonraki değişiklik koleksiyona otomatik yayılmaz. Her değişiklikte yeniden aktarım veya manuel koleksiyon düzenleme gerekir.

Spesifikasyon-önce modele geçerken Postman'ı keşif testleri için kullanabilir miyim?

Evet. Spesifikasyon-önce yaklaşım, tek seferlik keşif çağrılarını engellemez. Postman'ı manuel denemeler için kullanabilirsiniz. Önemli olan, keşif koleksiyonunu sözleşme doğrulamasının gerçeklik kaynağı olarak kabul etmemektir.

Spesifikasyonun gerçek API'den saptığını nasıl anlarım?

Bunun için sözleşme test katmanı gerekir. API sunucusu test zamanında gelen istekleri ve dönen yanıtları OpenAPI spesifikasyonuna göre doğrulamalıdır.

Spectral gibi araçlar spesifikasyonun iç tutarlılığını kontrol eder. Ancak gerçek uygulama davranışının spesifikasyondan sapıp sapmadığını görmek için çalışma zamanı doğrulaması gerekir.

Apidog Postman'ı tamamen değiştirir mi?

Bu ekibinizin iş akışına bağlıdır. Apidog tasarım, mocking, test ve dokümantasyonu tek çalışma alanında yönetir. Postman'ı ağırlıklı olarak sözleşme testleri ve regresyon paketleri için kullanıyorsanız Apidog bu alanı kapsayabilir.

Ekibiniz CI'da Postman collection runner kullanıyorsa veya kapsamlı koleksiyon script'lerine sahipse, Postman ile test etme iş akışı spesifikasyon-önce tasarımın yanında değerlendirilebilir. En doğru karar için bir deneme sprint'i çalıştırın.

`openapi.yaml` dosyam zaten güncel değilse ne yapmalıyım?

Önce spesifikasyonu uzlaştırmanız gerekir. Kestirme yol yoktur.

Yapılacak iş:

Mevcut API davranışını çıkarın.
openapi.yaml ile karşılaştırın.
YAML'yi gerçek davranışı yansıtacak şekilde güncelleyin.
Bundan sonra YAML'yi ana sözleşme kaynağı yapın.
Test, mock ve dokümantasyonu bu kaynaktan türetin.

Sonuç

Swagger belgeleri ve Postman koleksiyonları, aralarında bağlayıcı bir mekanizma olmayan iki ayrı yapıt oldukları için kayar. Bu bir ekip disiplini problemi değil, çift bakım modelinin doğal sonucudur.

Daha sağlam model şudur:

Git'te tek OpenAPI dosyası
        ↓
Dokümantasyon + Mock + Test

Apidog'u indirin, mevcut OpenAPI spesifikasyonunuzu içe aktarın ve tek dosyadan belgelerin, mock'ların ve testlerin nasıl üretildiğini deneyin. Spesifikasyon-Önce Modu'nu değerlendiriyorsanız güncel kapsam ve erişim bilgileri için Apidog Spesifikasyon-Önce Modu sayfasına bakın.

10 En Ucuz LLM API Sağlayıcıları 2026

Tobias Hoffmann — Thu, 04 Jun 2026 10:24:56 +0000

Tek bir yapay zeka özelliği, farkında olmadan en büyük bulut kaleminiz haline gelebilir. GPT-5.5 veya Claude Opus üzerinden günde birkaç milyon tokenı liste fiyatından geçirdiğinizde, henüz hiçbir şey yayınlamadan aylık faturanız dört haneyi bulur. Modeli nereden çağırırsanız çağırın aynıdır; bu yüzden tam perakende fiyatı ödemek bir seçimdir, zorunluluk değil.

Apidog'u bugün deneyin

2026'da en ucuz LLM API'si genellikle model üreticisinin kendi uç noktası değildir. İndirimli geçitler, ön ödemeli kredi platformları ve açık model barındırma servisleri resmi fiyatların %40-80 altına inebilir. Ancak “en ucuz” sağlayıcıyı seçmek için önce iş yükünüzü, model ihtiyacınızı ve token kullanımınızı ölçmeniz gerekir.

TL;DR: 2026'daki en ucuz LLM API sağlayıcıları

Hızlı karar için:

Hypereal AI, Claude, GPT ve Gemini gibi premium modellere indirimli erişim isteyen ekipler için en güçlü seçenektir.
Blackmagic AI, birden çok sağlayıcıda tek ön ödemeli bakiye ve sabit indirim isteyenler için pratiktir.
DeepSeek, Google Gemini 3.5 Flash, Groq ve DeepInfra, yüksek hacimli veya açık model iş yüklerinde düşük maliyet sağlar.
Altyapıyı yönetebiliyorsanız, açık modelleri kendi sunucunuzda barındırmak ölçek büyüdüğünde en düşük maliyetli rota olabilir.

En hızlı tasarruf genellikle şu iki adımla gelir:

Göreve uygun en küçük modeli seçin.
Modeli resmi perakende uç noktası yerine indirimli veya açık model odaklı bir sağlayıcı üzerinden çağırın.

LLM API fiyatlarını doğru okumak

LLM maliyetini değerlendirirken yalnızca “model ucuz mu?” diye bakmayın. Aşağıdaki metrikleri kontrol edin.

1. Giriş ve çıkış tokenları ayrı faturalandırılır

Bir model 1M giriş tokenı için 1,32 $ / 1M çıkış tokenı için 7,92 $ diyorsa:

İstemde gönderdiğiniz tokenlar giriş maliyetidir.
Modelin ürettiği yanıt çıkış maliyetidir.
Çıkış tokenları genellikle giriş tokenlarından daha pahalıdır.

Bu nedenle uzun yanıt üreten chatbot'lar, uzun prompt alan ama kısa yanıt veren sınıflandırma işlerinden daha pahalıya gelebilir.

2. Liste fiyatı tavan fiyattır

Sağlayıcıların yayınladığı fiyatlar perakende fiyattır. Ağ geçitleri ve yeniden satıcılar toplu kapasite satın alarak indirim uygulayabilir. Bu baskı, sınır sınıfı modellerin daha ucuz hale geldiği 2026 Çin LLM fiyat savaşında da görülüyor.

3. Ön ödemeli kredi modeli çoğu zaman daha öngörülebilirdir

Aylık taban ücret yoksa yalnızca gerçek kullanım için ödeme yaparsınız. Ancak şu kalemleri kontrol edin:

Kredi yükleme ücreti
Minimum yükleme tutarı
Platform komisyonu
Anahtar bazlı harcama limiti
Gerçek zamanlı maliyet kaydı

4. Önbellekleme doğrudan maliyet düşürür

Aynı sistem prompt'unu, aynı doküman bağlamını veya aynı araç tanımlarını tekrar tekrar gönderiyorsanız istem önbellekleme maliyeti ciddi şekilde azaltabilir. Agent tabanlı uygulamalarda bu fark daha görünür olur.

5. Ücretsiz katmanlar test içindir

Ücretsiz LLM API katmanları PoC ve entegrasyon testi için faydalıdır. Üretim trafiği için genellikle hız limiti ve kota engeline takılırsınız. Ücretsiz rotaları denemek için şu kılavuzlara bakabilirsiniz:

Sağlayıcıları nasıl sıraladık?

Sıralama şu kriterlere göre yapıldı:

İndirim sonrası gerçek token başına maliyet
Popüler model kataloğuna erişim
OpenAI uyumlu API desteği
Ön ödemeli veya öngörülebilir faturalandırma
Harcama limiti ve maliyet takibi
Üretime taşıma kolaylığı

Yalnızca az kullanılan tek bir modelde ucuz olan sağlayıcı, yaygın modellerde istikrarlı indirim sunan sağlayıcıdan daha düşük değerlendirilir.

2026'daki en ucuz 10 LLM API sağlayıcısı

1. Hypereal AI: premium modellere indirimli erişim

Hypereal AI, özellikle Claude Opus, Claude Sonnet, GPT-5.5 ve Gemini 3.5 gibi pahalı modelleri daha düşük maliyetle kullanmak isteyen ekipler için öne çıkar. Kodlama planı, Claude Opus 4.7 için resmi API oranlarının yaklaşık %32 altında, Claude Sonnet için ise yaklaşık %77 altında fiyat sağlar ve OpenAI uyumlu uç nokta sunar.

Fiyatlandırma kredi tabanlıdır:

100 kredi = 1 $
Abonelik yok
Kullanım kadar ödeme
Giriş ve çıkış tokenları ayrı ölçülür
İstem önbelleği ve Hypereal Önbelleği tekrarlı token maliyetini düşürür
Ücretsiz katmanda ödeme yapmadan önce test için dakikada 60 istek hakkı bulunur

Kodlama planı, paket büyüklüğüne göre çarpan uygular: 10 dolarlık pakette 4,4x, 1.000 dolarlık pakette 7,7x seviyesine kadar çıkar. Bu çarpan Claude Opus 4.7 ve 4.6, Claude Sonnet 4.6, GPT-5.5 ve Gemini 3.5 Thinking/Fast gibi kodlama sınıfı modellere uygulanır.

Ne zaman seçilmeli?

Claude, GPT veya Gemini kullanan kodlama agent'ları çalıştırıyorsanız
Tek bir uygun fiyatlı faturayla metin, görüntü ve video modellerine erişmek istiyorsanız
Claude Opus 4.8 fiyatları sizi zorluyorsa

2. Blackmagic AI: çoklu sağlayıcı için ön ödemeli ağ geçidi

Blackmagic AI, OpenRouter benzeri bir ağ geçidi sunar. Farkı, sağlayıcılar arasında tek bakiye ve model kataloğunda %48-74 arası indirim sağlamasıdır.

Desteklenen sağlayıcılar arasında OpenAI, Anthropic, Google, Meta, Mistral, xAI, DeepSeek, Qwen, Black Forest Labs, Moonshot AI, Cohere, Perplexity ve Stability AI bulunur.

Faturalandırma tarafında:

Abonelik yok
9,99 $ - 499,99 $ arası yüklemeler
İstek başına gerçek zamanlı maliyet kaydı
API anahtarı başına aylık harcama limiti
OpenAI uyumlu rotalar

Blackmagic'in kendi hesaplayıcısına göre aylık 20 milyon GPT-5.5 tokenı, perakende yaklaşık 250 $ yerine 66 $ seviyesinde olabilir.

Ne zaman seçilmeli?

Birden çok sağlayıcıyı tek bakiye ile kullanmak istiyorsanız
Maliyet takibini API anahtarı seviyesinde yapmak istiyorsanız
Modalite veya sağlayıcı bazında ayrı fatura yönetmek istemiyorsanız

3. DeepSeek: düşük maliyetli sınır sınıfı model

DeepSeek, sınır sınıfı muhakeme ve kodlama işlerinde agresif fiyatlandırmasıyla öne çıkar. Yerel API'si düşük maliyetlidir; yoğun olmayan saatlerdeki indirimler maliyeti daha da düşürebilir.

Modeller açık ağırlıklıdır. Bu nedenle üç rota mümkündür:

DeepSeek API'sini doğrudan kullanmak
Bir ağ geçidi üzerinden çağırmak
Modeli kendi altyapınızda barındırmak

Ne zaman seçilmeli?

Yüksek hacimli muhakeme veya kodlama işleri yapıyorsanız
ABD dışı bir sınır modelini kullanmak sizin için uygunsa
Açık ağırlık esnekliği istiyorsanız

4. Google Gemini 3.5 Flash: yüksek hacimli görevler için ucuz flash katman

Gemini 3.5 Flash, Google'ın yüksek hacimli ve maliyet hassasiyetli işler için sunduğu hızlı model katmanıdır. Özetleme, sınıflandırma, çıkarma ve yönlendirme gibi görevlerde sınır modellerine göre daha düşük maliyetle çalışır.

Token başına fiyat ve kullanım alanları için Gemini 3.5 Flash fiyatlandırma dökümüne bakabilirsiniz.

Ne zaman seçilmeli?

Milyonlarca küçük çağrı yapıyorsanız
Her çağrı için üst düzey muhakeme gerekmiyorsa
Özetleme, etiketleme, sınıflandırma veya veri çıkarma yapıyorsanız

5. Groq: açık modeller için hızlı ve ucuz çıkarım

Groq, açık modelleri özel LPU donanımında çalıştırır. Avantajı, düşük token başına fiyatla yüksek token/saniye hızını birlikte sunmasıdır.

GroqCloud:

OpenAI uyumludur
Llama, Qwen ve Gemma gibi açık modelleri destekler
Düşük gecikme isteyen uygulamalara uygundur

Katalog, tam bir toplayıcı kadar geniş değildir. Bu yüzden tüm iş yükleri için değil, desteklenen açık modeller için idealdir.

Ne zaman seçilmeli?

Sesli asistan veya gerçek zamanlı araç geliştiriyorsanız
Düşük gecikme ve düşük maliyet aynı anda gerekiyorsa
Açık model kullanmak istiyorsanız

6. DeepInfra: düşük maliyetli açık model barındırma

DeepInfra, açık modeller için sade, token başına ödeme yapan bir barındırma servisidir. OpenAI uyumlu API sunar ve Llama, Qwen, Mistral, DeepSeek varyantları gibi modellerde rekabetçi oranlar sağlar.

Avantajları:

Abonelik yok
Minimum kullanım şartı yok
Token başına ödeme
OpenAI uyumlu entegrasyon

Ne zaman seçilmeli?

Ham token başına fiyat sizin için en önemli kriterse
Açık model kullanıyorsanız
Hobi projesi veya maliyet sınırlı üretim uygulaması geliştiriyorsanız

7. Together AI: açık modeller ve ince ayar

Together AI, OpenAI uyumlu API arkasında 200'den fazla açık model sunar. Ayrıca ince ayar ve özel uç nokta seçenekleri sağlar.

Tipik kullanım akışı:

Paylaşımlı açık model uç noktasıyla başlayın.
Modeli kendi verinizle ince ayarlayın.
Trafik büyüdüğünde ayrılmış dağıtıma taşıyın.

Qwen 3.7 API kılavuzumuz, bu platformlarda iyi çalışan model türlerine örnek verir.

Ne zaman seçilmeli?

Açık ağırlık modeller üzerinde standartlaşıyorsanız
Ucuz başlangıç ve ince ayar yolu istiyorsanız
Sağlayıcı değiştirmeden ölçeklemek istiyorsanız

8. Fireworks AI: üretim odaklı açık model çıkarımı

Fireworks AI, açık modelleri üretimde kullanmak isteyen ekipler için hızlı ve güvenilir çıkarım sunar.

Öne çıkan özellikler:

Fonksiyon çağırma
JSON modu
İnce ayar
OpenAI uyumlu API
Rekabetçi token başına fiyat

Ne zaman seçilmeli?

Açık modelleri üretimde kullanıyorsanız
Yapılandırılmış çıktı gerekiyorsa
Ham API etrafında ek mühendislik maliyetini azaltmak istiyorsanız

9. OpenRouter: geniş katalog, fakat ücretleri kontrol edin

OpenRouter, geniş model kataloğu nedeniyle birçok geliştirici için varsayılan seçimdir. Tek anahtarla 300'den fazla modele erişebilirsiniz.

Ancak maliyet hesabında şu ücretleri dahil edin:

Kredi satın alımında minimum 0,80 $ olmak üzere %5,5 ücret
Ayda bir milyonu aşan “kendi anahtarını getir” isteklerinde %5 ek ücret
Sağlayıcı liste fiyatı

Genişlik ve hızlı deneme için kullanışlıdır, fakat ölçekte her zaman en ucuz seçenek değildir. Alternatifleri değerlendirmek için en iyi OpenRouter alternatifleri kılavuzuna bakabilirsiniz.

Ne zaman seçilmeli?

Çok sayıda modeli hızlıca denemek istiyorsanız
En düşük maliyet değil, katalog genişliği önceliğinizse

10. Açık modelleri kendi sunucunuzda barındırmak: ölçek için en ucuz rota

Yeterli hacme ulaştığınızda açık modelleri kendi altyapınızda çalıştırmak token başına yeniden satıcı maliyetini ortadan kaldırır. Örneğin:

vLLM ile model sunucusu
LiteLLM ile OpenAI uyumlu proxy
Ayrılmış GPU kapasitesi
Kendi loglama, rate limit ve izleme katmanınız

Bu yöntemde token için değil, GPU için ödeme yaparsınız. Ancak operasyonel yük size aittir:

Kapasite planlama
Uptime
Model yükseltmeleri
Güvenlik
Ölçekleme
İzleme

Ne zaman seçilmeli?

GPU'nuz sürekli meşgul kalacak kadar trafik varsa
Operasyonel altyapıyı yönetebiliyorsanız
Açık model kullanımı stratejik tercihinizse

En ucuz LLM API sağlayıcıları karşılaştırması

Sağlayıcı	En ucuz olduğu durumlar	Fiyatlandırma modeli	Örnek fiyat veya indirim	OpenAI uyumlu
Hypereal AI	Premium modeller + medya	Krediler (100 = 1$)	Opus ~%32 / Sonnet ~%77 resmi fiyatın altında	Evet
Blackmagic AI	Ön ödemeli çoklu sağlayıcı	Ön ödemeli krediler	GPT-5.5 1M başına 1,32 $ / 7,92 $ (%74 indirim)	Evet
DeepSeek	Bütçe dostu sınır modelleri	Kullandıkça öde	En düşük sınır oranları arasında	Evet
Gemini 3.5 Flash	Yüksek hacimli görevler	Kullandıkça öde	En düşük büyük isimli flash katman	Evet
Groq	Hızlı + ucuz açık modeller	Kullandıkça öde	Düşük oran, yüksek hız	Evet
DeepInfra	Açık model barındırma	Kullandıkça öde	En düşük açık model token başına	Evet
Together AI	Açık modeller + ince ayar	Kullandıkça öde	Rekabetçi açık oranlar	Evet
Fireworks AI	Üretim açık modelleri	Kullandıkça öde	Rekabetçi açık oranlar	Evet
OpenRouter	Genişlik + kolaylık	Krediler + %5,5 ücret	Liste fiyatı artı ücretler	Evet
Kendi sunucunda barındırma (vLLM)	Ölçek	Yalnızca altyapı maliyeti	Ölçekte token başına neredeyse sıfır	Evet

Uygulamada maliyeti düşürmek için 5 adım

Ucuz sağlayıcı seçmek yeterli değildir. Prompt ve yönlendirme stratejinizi de optimize edin.

1. Modeli doğru boyutlandırın

Her isteği en pahalı modele göndermeyin. Basit bir yönlendirme yapısı kurun:

Sınıflandırma → flash model
Özetleme → flash model
JSON çıkarma → ucuz açık model
Karmaşık muhakeme → sınır model
Kodlama agent'ı → Claude/GPT/Gemini indirimli rota

Örnek karar mantığı:

function selectModel(task) {
  if (["classify", "summarize", "extract"].includes(task.type)) {
    return "gemini-3.5-flash";
  }

  if (task.type === "realtime") {
    return "groq-open-model";
  }

  if (task.type === "coding-agent") {
    return "claude-sonnet-discounted";
  }

  return "deepseek-reasoner";
}

2. İstem önbelleklemesini kullanın

Aynı sistem prompt'u, tool şemaları ve uzun bağlam tekrar gönderiliyorsa önbellekleme açın. Agent sistemlerinde maliyetin büyük kısmı tekrar eden bağlamdan gelebilir.

3. Gecikme izin veriyorsa batch kullanın

Arka plan işleri için tek tek istek atmak yerine toplu istekler kullanın. Özellikle sınıflandırma, etiketleme ve çıkarma işlemlerinde batch daha verimli olabilir.

4. Büyük ön ödemeli paketleri değerlendirin

İndirim katmanları genellikle hacmi ödüllendirir. Hypereal'in kodlama çarpanı paket büyüklüğüne göre 4,4x'ten 7,7x'e çıkar. Trafiğiniz öngörülebilirse küçük yüklemeler yerine daha büyük paketler daha avantajlı olabilir.

5. API anahtarı bazında harcama limiti koyun

Kontrolsüz bir döngü, yanlış retry ayarı veya hatalı agent akışı bakiyeyi hızla tüketebilir. Her ortam için ayrı anahtar ve limit kullanın:

dev: düşük limit
staging: orta limit
production: uyarılı ve izlenen limit
agent-experiments: ayrı bütçe

OpenAI uyumlu sağlayıcıya geçiş örneği

Listedeki sağlayıcıların çoğu OpenAI uyumlu format desteklediği için geçiş genellikle baseURL, apiKey ve model değişikliğidir.

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.LLM_API_KEY,
  baseURL: process.env.LLM_BASE_URL
});

const response = await client.chat.completions.create({
  model: process.env.LLM_MODEL,
  messages: [
    {
      role: "system",
      content: "Kısa, teknik ve doğrudan yanıt ver."
    },
    {
      role: "user",
      content: "Bu API yanıtını özetle ve hata risklerini listele."
    }
  ],
  temperature: 0.2
});

console.log(response.choices[0].message.content);
console.log(response.usage);

.env örneği:

LLM_API_KEY=your_key
LLM_BASE_URL=https://provider.example.com/v1
LLM_MODEL=provider-model-name

Geçişten sonra özellikle şunları test edin:

Streaming davranışı
usage alanı
Tool/function calling uyumluluğu
JSON çıktının geçerliliği
Rate limit davranışı
Retry sonrası maliyet

Apidog ile token maliyetlerini ölçün ve karşılaştırın

Pazarlama sayfaları fiyatı gösterir; faturanız ise gerçek prompt'larınızın kaç token tükettiğine bağlıdır. Bu yüzden sağlayıcı seçmeden önce kendi isteklerinizi ölçün.

Apidog, OpenAI uyumlu LLM API'lerini test etmek için pratik bir API platformudur. Her sağlayıcı için aynı /chat/completions isteğini çalıştırabilir, yanıttaki usage bloğunu okuyabilir ve maliyeti karşılaştırabilirsiniz.

Uygulanabilir test akışı:

Her sağlayıcı için ayrı ortam oluşturun.
Ortama base_url, api_key ve model değişkenlerini ekleyin.
Aynı prompt'u tüm sağlayıcılarda çalıştırın.
usage.prompt_tokens ve usage.completion_tokens değerlerini kaydedin.
Sağlayıcının fiyatıyla çarpıp gerçek maliyeti hesaplayın.
Aynı testi aylık tekrarlayın; fiyatlar ve yönlendirme değişebilir.

Örnek istek gövdesi:

{
  "model": "{{model}}",
  "messages": [
    {
      "role": "system",
      "content": "Kısa ve teknik yanıt ver."
    },
    {
      "role": "user",
      "content": "Bu metni özetle ve üç aksiyon maddesi çıkar."
    }
  ],
  "temperature": 0.2
}

Kontrol etmeniz gereken yanıt alanı:

{
  "usage": {
    "prompt_tokens": 1200,
    "completion_tokens": 350,
    "total_tokens": 1550
  }
}

Basit maliyet hesabı:

const inputTokens = 1200;
const outputTokens = 350;

const inputPricePerMillion = 1.32;
const outputPricePerMillion = 7.92;

const cost =
  (inputTokens / 1_000_000) * inputPricePerMillion +
  (outputTokens / 1_000_000) * outputPricePerMillion;

console.log(`İstek maliyeti: $${cost.toFixed(6)}`);

Bu listedeki sağlayıcıların OpenAI uyumlu olması karşılaştırmayı kolaylaştırır: aynı istek, aynı parametreler, gerçek token sayıları. API test iş akışını genişletmek isterseniz en iyi Postman alternatifleri kılavuzundaki yaklaşımı da kullanabilirsiniz. Kısa listenizi test etmek için Apidog'u indirin.

Sıkça sorulan sorular

2026'da en ucuz LLM API'si nedir?

Premium Claude ve GPT modelleri için Hypereal AI'nin kodlama planı, resmi oranların altında fiyat verdiği için pratikte en ucuz rotalardan biridir. Açık modeller için DeepInfra ve Groq düşük token başına fiyat sunar. DeepSeek ise sınır sınıfı kaliteyi daha düşük maliyetle isteyenler için güçlü bir seçenektir.

Ücretsiz LLM API var mı?

Evet, ancak limitlidir. Hypereal dakikada 60 istek sunan ücretsiz katmana sahiptir. Büyük laboratuvarların çoğu da test için hız sınırlı ücretsiz kullanım verir. Ücretsiz rotalar için Claude Opus 4.8'i ücretsiz kullanma kılavuzuna bakabilirsiniz.

Bu sağlayıcılar neden doğrudan OpenAI veya Anthropic'ten daha ucuz olabilir?

Ağ geçitleri ve yeniden satıcılar kapasiteyi toplu satın alabilir ve indirimli sunabilir. Açık model barındırma servisleri ise maliyeti ölçekli altyapıyla düşürür. Aynı model veya benzer yetenek, daha ucuz bir kanal üzerinden erişilebilir hale gelir.

Geçiş yaparsam mevcut kodum çalışır mı?

Çoğu durumda evet. OpenAI uyumlu sağlayıcılarda genellikle şu üç alanı değiştirmeniz yeterlidir:

base_url
api_key
model

Yine de streaming, tool calling ve usage alanlarını mutlaka test edin.

Claude Code veya Cursor gibi kodlama agent'ları için en ucuz API hangisi?

Hypereal'in kodlama planı, Claude ve GPT modellerini perakende fiyatının altında sunar ve Claude Code, Cursor, Cline, Aider, Continue.dev ve OpenCode ile çalışır. Daha fazla tasarruf için aracı token maliyeti kılavuzundaki taktiklerle birlikte kullanın.

En ucuz seçenek her zaman en iyi seçenek mi?

Hayır. Görev için zayıf kalan ucuz model, yeniden deneme, insan düzeltmesi veya hatalı çıktı nedeniyle daha pahalıya gelebilir. Önce doğru modeli seçin, sonra o modeli en ucuz ve güvenilir kanaldan çağırın.

Hangi ucuz LLM API'sini seçmelisiniz?

Kararı iş yüküne göre verin:

Kodlama agent'ları için Claude, GPT veya Gemini kullanıyorsanız: Hypereal AI ve kodlama planı.
Birçok sağlayıcıda tek ön ödemeli bakiye istiyorsanız: Blackmagic AI.
Açık modeller kullanıyorsanız: En düşük oranlar için DeepInfra ve Groq; ince ayar veya üretim özellikleri için Together AI ve Fireworks AI.
Yüksek hacimli bütçe dostu işler yapıyorsanız: DeepSeek, Gemini 3.5 Flash veya yeterli hacimde kendi sunucunuzda barındırma.

Son adım: geçiş yapmadan önce fiyatı kendi verinizle kanıtlayın. Apidog'da OpenAI uyumlu bir istek oluşturun, gerçek prompt'larınızı her sağlayıcıya karşı çalıştırın ve kazananı token sayılarıyla seçin.

Git Entegrasyonlu API Dokümantasyonu: En İyi 6 Araç

Tobias Hoffmann — Thu, 04 Jun 2026 08:29:08 +0000

Kod, birinin bir vikiyi güncelleyebileceğinden daha hızlı devreye girdiğinde API dokümantasyonu hızla eskir. Bir uç nokta değişir, örnek aynı kalır ve geliştirici artık dönmeyen bir yanıt alanını debug etmeye başlar. Bunu önlemenin pratik yolu docs-as-code yaklaşımıdır: dokümantasyonu depoda dosya olarak tutun, değişiklikleri pull request içinde inceleyin ve siteyi her merge sonrası otomatik yeniden oluşturun.

Apidog'u bugün deneyin

Dokümantasyon artık yalnızca insanlar tarafından okunmuyor. Yapay zeka ajanları, IDE asistanları ve kodlama araçları referans dokümanlarını sürekli tüketiyor. Bu araçlar güncel, yapılandırılmış ve doğrudan kaynaktan üretilmiş içerik bekliyor. Git'e bağlı bir doküman platformu, hem insanlara yönelik doküman sitesini hem de makine tarafından okunabilir OpenAPI spesifikasyonunu aynı versiyonlanmış dosyalardan üretir.

Bu rehber, 2026'da Git entegrasyonuna sahip API dokümantasyon araçlarını uygulama odaklı şekilde karşılaştırır. Hepsi bir arada seçenek olan Apidog ile başlayıp, ardından özel dokümantasyon platformlarına geçiyoruz. Daha geniş bir Git tabanlı API iş akışı kuruyorsanız, Git ile çalışan API araçları derlemesiyle birlikte okuyabilirsiniz.

TL;DR: Git entegrasyonuna sahip en iyi API doküman platformları

Apidog: Dokümantasyon, test, mock ve API tasarımını aynı OpenAPI spesifikasyonundan yöneten en güçlü hepsi bir arada seçenek.
Mintlify: Markdown ve OpenAPI tabanlı docs-as-code portalı isteyen ekipler için güçlü bir seçenek.
Fern: Tek spesifikasyondan SDK ve dokümantasyon üretmek isteyen API sağlayıcıları için uygun.
Redocly: OpenAPI linting, kurallar ve spesifikasyon yönetimi için güçlü.
GitBook: Görsel düzenleyici ile Git senkronizasyonunu birleştirmek isteyen ekipler için iyi.
Read the Docs: Sphinx veya MkDocs kullanan açık kaynak projeler için sağlam ve Git'e özgü bir seçenek.

Temel prensip basit: API sözleşmeniz ve dokümantasyonunuz iki farklı sistemden geliyorsa zamanla birbirinden sapar.

API dokümanları neden Git entegrasyonuna ihtiyaç duyar?

Git destekli dokümantasyon, dokümanların API gerçekliğinden kopmasına neden olan manuel adımları azaltır.

1. OpenAPI dosyası tek kaynak olur

Referans dokümanlarınız deponuzdaki OpenAPI dosyasından oluşturuluyorsa, uç nokta değişikliğiyle doküman değişikliği aynı commit veya pull request içinde incelenir.

Örnek depo yapısı:

repo/
  api/
    openapi.yaml
  docs/
    guides/
      authentication.md
      pagination.md
  src/

Bu yapıda api/openapi.yaml dosyası endpoint, parametre, schema ve response örneklerinin kaynağı olur. OpenAPI dosyasını temiz tutmak için Git ile OpenAPI versiyon kontrolü yaklaşımını kullanabilirsiniz.

2. Pull request içinde doküman önizlemesi yapılır

Ham YAML veya Markdown incelemek yeterli değildir. İyi bir Git entegrasyonu, her branch için doküman önizlemesi üretmelidir.

Beklenen akış:

feature/add-payment-status
        ↓
OpenAPI değişir
        ↓
Doküman sitesi branch preview olarak build edilir
        ↓
Reviewer endpoint ve dokümanı birlikte inceler
        ↓
Merge sonrası canlı doküman yeniden oluşturulur

3. Branch tabanlı versiyonlama mümkün olur

API'nizin v3 sürümü üzerinde çalışıyorsanız, dokümantasyon da aynı branch üzerinde yaşamalıdır. Bu, spec-as-code modelinin doğal sonucudur.

Örnek:

main          → v2 production docs
release/v3    → v3 beta docs
feature/oauth → geçici PR preview

4. Yapay zeka ajanları güncel kaynak okur

Kodlama asistanları, API entegrasyonu üretirken dokümanlarınızı okuyabilir. Eğer dokümanlar eskiyse, yanlış kod önerirler. Git'ten tetiklenen build süreci, OpenAPI tabanlı referansın güncel kalmasını sağlar.

Git entegrasyonlu doküman aracında nelere bakmalı?

Bir aracın gerçekten Git uyumlu olup olmadığını anlamak için şu özellikleri kontrol edin:

Çift yönlü senkronizasyon

Web editöründe yapılan değişiklikler Git'e commit edilebilmeli, Git'teki değişiklikler de platforma yansıyabilmeli.
PR önizlemeleri

Her pull request, oluşturulmuş dokümantasyon önizlemesi üretmeli.
Branch tabanlı versiyonlama

Branch'ler doküman versiyonlarına eşlenebilmeli.
OpenAPI senkronizasyonu

OpenAPI değiştiğinde referans dokümanları otomatik güncellenmeli.
Yapılandırılmış çıktı

Arama, AI ajanları ve entegrasyon araçları için makine tarafından okunabilir içerik üretilebilmeli.

Git entegrasyonuna sahip en iyi API dokümantasyon araçları

1. Apidog: Testleri ve dokümanları aynı spesifikasyondan üretin

Apidog, dokümantasyon sapmasını azaltmak için API yaşam döngüsünü tek bir OpenAPI tanımı etrafında toplar. Dokümanlar, request örnekleri, mock server ve test senaryoları aynı API sözleşmesinden türetilir.

Bir endpoint değiştiğinde sadece doküman güncellenmez; ilgili mock davranışı ve test senaryoları da aynı sözleşmeye bağlı kalır.

Tipik Apidog akışı:

OpenAPI dosyasını Git deposundan içe aktarın veya senkronize edin.
Endpoint, schema ve örnekleri Apidog içinde düzenleyin.
Dokümantasyon, mock ve testleri aynı spesifikasyondan üretin.
Değişiklikleri Git branch'i üzerinden inceleyin.
Merge sonrası yayınlanan dokümanları güncelleyin.

Apidog'un Git entegrasyonu ve senkronizasyonu, GitHub, GitLab ve self-hosted Git senaryolarına bağlanabilir. Spesifikasyon öncelikli mod sayesinde dokümantasyon, gerçekten test ettiğiniz sözleşmeden üretilir.

En iyisi: Dokümantasyon, test, mock ve API tasarımını tek Git destekli spesifikasyondan yönetmek isteyen ekipler.

2. Mintlify: AI uyumlu docs-as-code portalı

Mintlify, Markdown ve OpenAPI dosyalarını Git deposundan senkronize eder. Her push sonrası dokümanları yeniden oluşturabilir ve pull request için branch preview sunabilir.

Öne çıkan kullanım şekli:

docs/
  introduction.mdx
  quickstart.mdx
  api-reference/
openapi.yaml
mint.json

Yazarlar web editörüyle çalışabilir, mühendisler ise dosyaları doğrudan Git içinde düzenleyebilir. Değişiklikler Git'e geri commit edilir. Mintlify ayrıca AI ajanlarının dokümanları daha iyi tüketebilmesi için yapılandırılmış çıktılara odaklanır.

En iyisi: Modern, cilalı ve AI uyumlu bir docs-as-code portalı isteyen mühendislik ve dokümantasyon ekipleri.

3. Fern: Tek spesifikasyondan SDK ve dokümantasyon üretin

Fern, Git'te tutulan tek API tanımından hem SDK hem de dokümantasyon oluşturur. Bu özellikle istemci kütüphaneleri gönderen API sağlayıcıları için önemlidir.

Pratik avantaj:

Tek API tanımı
      ↓
TypeScript SDK
Python SDK
Go SDK
Dokümantasyon sitesi

Bu yaklaşım, dokümandaki örneklerin SDK davranışından kopmasını azaltır.

En iyisi: Tek bir spesifikasyondan hem dokümantasyon hem de istemci SDK'ları üretmek isteyen API ekipleri.

4. Redocly: OpenAPI yönetimi ve linting

Redocly, OpenAPI dosyalarını yönetilen bir yapıt olarak ele alan ekipler için güçlüdür. Çok dosyalı OpenAPI yapıları, özel lint kuralları ve branch preview desteği sunar.

Örnek kullanım:

# redocly.yaml
apis:
  core@v1:
    root: ./openapi/openapi.yaml

rules:
  operation-operationId: error
  no-unused-components: warn

Bu tür kurallar, API tasarım standartlarını manuel review yorumları yerine CI sürecinde uygulatmanıza yardımcı olur. Benzer şekilde OpenAPI doğrulayıcı araçları ile spesifikasyon kalitesini artırabilirsiniz.

En iyisi: Birden fazla ekip arasında API tasarım standartlarını uygulamak isteyen kuruluşlar.

5. GitBook: Görsel düzenleme ve Git senkronizasyonu

GitBook, teknik olmayan ekip üyeleri için kullanımı kolay bir görsel editör sunar. İçerik Git ile senkronize edilebilir, böylece ürün yöneticileri ve yazarlar web arayüzünden katkı verirken mühendisler dosya tabanlı çalışabilir.

GitBook, OpenAPI merkezli araçlara göre daha genel amaçlıdır. Bu nedenle ürün rehberleri, onboarding sayfaları ve konsept dokümanları için güçlüdür.

En iyisi: Ürün, dokümantasyon ve mühendislik ekiplerinin birlikte içerik ürettiği ekipler.

6. Read the Docs: Açık kaynak için Git-native dokümantasyon

Read the Docs, Sphinx veya MkDocs kaynaklarından dokümantasyon oluşturur ve Git commit'lerinde yeniden build eder.

Tipik yapı:

docs/
  index.md
  installation.md
  api.md
mkdocs.yml

OpenAPI referans deneyimi özel API doküman platformlarına göre daha manuel olabilir. Ancak açık kaynak projelerde, versiyonlama ve Git tabanlı build süreci oldukça olgundur.

En iyisi: Sphinx veya MkDocs kullanan açık kaynak ve mühendislik ekipleri.

API doküman platformları karşılaştırması

Platform	En iyisi	Spesifikasyon senkronizasyonu	PR önizlemeleri	Hepsi bir arada
Apidog	Tek spesifikasyondan dokümanlar, testler ve mock	Evet, OpenAPI	Git aracılığıyla	Evet
Mintlify	Docs-as-code ve AI uyumluluğu	Evet	Evet	Hayır
Fern	SDK ve doküman üretimi	Evet	Evet	Hayır
Redocly	OpenAPI yönetimi ve linting	Evet	Evet	Hayır
GitBook	Görsel düzenleme ve Git	Kısmi	Evet	Hayır
Read the Docs	Açık kaynak dokümantasyonu	Build süreciyle	Evet	Hayır

Git senkronize API dokümanları pratikte nasıl çalışır?

Uygulanabilir bir iş akışı şu şekilde kurulabilir:

1. OpenAPI dosyasını depoya ekleyin

mkdir -p api
touch api/openapi.yaml
git add api/openapi.yaml
git commit -m "Add OpenAPI specification"

OpenAPI dosyasını GitHub ile senkronize etmek için OpenAPI spesifikasyonunu GitHub ile senkronize etme rehberini kullanabilirsiniz.

2. Doküman aracını depoya bağlayın

Araç, openapi.yaml dosyasını okuyup referans sayfalarını oluşturmalıdır. Örnek kaynak tanımı:

openapi: 3.0.3
info:
  title: Payments API
  version: 1.0.0
paths:
  /payments:
    get:
      summary: Ödemeleri listele
      responses:
        "200":
          description: Başarılı yanıt

3. Değişiklikleri branch üzerinde yapın

git checkout -b feature/payment-status

Endpoint veya schema değişikliğini aynı branch içinde yapın.

4. Pull request önizlemesini inceleyin

Reviewer şunları kontrol etmelidir:

Endpoint adı doğru mu?
Parametre açıklamaları yeterli mi?
Response schema gerçek API ile uyumlu mu?
Kod örnekleri çalışıyor mu?
Breaking change varsa versiyon notu var mı?

5. Merge sonrası dokümantasyonu otomatik yayınlayın

Merge işlemi canlı doküman sitesinin yeniden build edilmesini tetiklemelidir. Böylece API değişikliği ve dokümantasyon güncellemesi aynı teslimat akışında kalır.

AI ajanları Git entegrasyonlu dokümanları nasıl okur?

AI ajanları için dokümantasyonun üç özelliği önemlidir:

1. OpenAPI'den üretilmiş yapılandırılmış referans

Ajanlar serbest metinden tahmin yapmak yerine OpenAPI içindeki tipleri, zorunlu alanları, enum değerlerini ve örnekleri okuyabilir.

Örnek:

components:
  schemas:
    Payment:
      type: object
      required:
        - id
        - status
      properties:
        id:
          type: string
        status:
          type: string
          enum:
            - pending
            - succeeded
            - failed

Bu yapı, AI aracının geçersiz status değeri üretme ihtimalini azaltır.

2. Makine tarafından okunabilir keşif dosyaları

llms.txt gibi dosyalar, asistanlara dokümantasyon haritası sağlayabilir. Bu dosyalar her build sırasında repodan üretilirse güncel kalır.

3. MCP ve araç uç noktaları

Bazı platformlar dokümanları Model Context Protocol veya benzeri araç uç noktaları üzerinden sunar. Bu uç noktaların güvenilirliği, doküman kaynağının güncelliğine bağlıdır. Git tetiklemeli rebuild bu yüzden önemlidir.

Kaçınılması gereken docs-as-code hataları

1. OpenAPI yanında ayrı referans metni yazmak

Referans bilgisi OpenAPI'den üretilmelidir. El yazısı sayfaları şu içerikler için ayırın:

Hızlı başlangıç
Kimlik doğrulama rehberi
Konsept açıklamaları
En iyi pratikler
Migration rehberleri

2. PR önizlemesi olmadan merge etmek

YAML geçerli olabilir ama oluşturulan dokümanda problem çıkabilir. Her PR için render edilmiş önizleme kullanın.

3. Tek devasa OpenAPI dosyası kullanmak

Büyük spesifikasyonları parçalara ayırın:

openapi/
  openapi.yaml
  paths/
    payments.yaml
    customers.yaml
  components/
    schemas/
      payment.yaml
      customer.yaml

Bu yapı review ve merge conflict yönetimini kolaylaştırır.

4. Teknik olmayan katkıcıları dışarıda bırakmak

Yazarlar ve ürün yöneticileri ham YAML düzenlemek istemeyebilir. Git'e commit atan web editörü olan araçlar bu noktada faydalıdır.

5. Versiyonları kopyalayarak çoğaltmak

Her sürüm için sayfaları kopyalamak yerine branch veya release tabanlı versiyonlama kullanın.

Kötü yaklaşım:

docs/v1/payment.md
docs/v2/payment.md
docs/v3/payment.md

Daha sürdürülebilir yaklaşım:

main       → mevcut sürüm
release/v2 → v2 bakım branch'i
release/v3 → v3 geliştirme branch'i

Apidog ile Git senkronize API dokümanları oluşturma

Dokümantasyonun API'den sapmasını istemiyorsanız, en pratik yaklaşım dokümanları zaten test ettiğiniz spesifikasyondan üretmektir. Apidog bu akışı tek projede toplar:

OpenAPI dosyanızı Git'ten içe aktarın veya senkronize edin.
Endpoint, schema ve örnekleri tek sözleşme üzerinde yönetin.
Dokümanları, mock server'ı ve testleri aynı kaynaktan üretin.
Etkileşimli API portalı yayınlayın.
Değişiklikleri pull request içinde birlikte inceleyin.

Bu yaklaşımın avantajı bakım maliyetidir. Ayrı bir doküman aracı, ayrı bir test aracı ve ayrı bir mock aracı arasında senkronizasyon kurmak yerine tek sözleşme üzerinden ilerlersiniz.

Dosya tabanlı alternatifleri de değerlendiriyorsanız, Bruno'nun API dokümantasyon oluşturma yaklaşımına da bakabilirsiniz. Dokümanları doğrudan deponuzdaki spesifikasyondan yayınlamak için Apidog'u indirin.

Sıkça sorulan sorular

Git entegrasyonlu API dokümanları ne anlama gelir?

Dokümantasyonun ve OpenAPI spesifikasyonunun Git deposunda versiyonlanması anlamına gelir. Değişiklikler pull request üzerinden incelenir ve merge sonrası doküman sitesi otomatik yeniden oluşturulur.

Docs-as-code nedir?

Docs-as-code, dokümantasyonu yazılım geliştirme iş akışıyla yönetmektir: düz metin dosyaları, Git, pull request review ve CI/CD build süreci.

İyi bir Mintlify alternatifi nedir?

Yalnızca dokümantasyon portalı değil, API tasarımı, test, mock ve dokümantasyonu aynı Git senkronize spesifikasyondan yönetmek istiyorsanız Apidog güçlü bir alternatiftir. SDK üretimi öncelikliyse Fern, OpenAPI yönetimi öncelikliyse Redocly değerlendirilebilir.

API dokümanlarını kodumla aynı depoda tutabilir miyim?

Evet. Hatta önerilen yaklaşım budur. OpenAPI dosyasını ve doküman içeriğini kodun yanında tutmak, endpoint değişikliği ile dokümantasyon değişikliğinin aynı PR içinde incelenmesini sağlar. Bu, Git-native API geliştirme yaklaşımının temelidir.

Bu araçlar GitLab ve self-hosted Git destekliyor mu?

Çoğu platform GitHub ve GitLab destekler. Apidog, GitHub, GitLab ve self-hosted Git senaryolarıyla bağlanabilir. Kendi Git sunucunuzu kullanıyorsanız, seçtiğiniz aracın self-hosted entegrasyon desteğini doğrulamalısınız.

AI asistanları Git entegrasyonlu dokümanları daha güvenilir okur mu?

Güncel ve yapılandırılmış dokümanları daha güvenilir okurlar. Dokümanlar her merge sonrası OpenAPI spesifikasyonundan yeniden üretildiğinde, AI aracı eski örnekler yerine güncel endpoint, schema ve parametreleri kullanır.

Apidog API dokümantasyonu için ücretsiz mi?

Apidog'un API tasarlamak ve spesifikasyondan dokümantasyon yayınlamak için kullanılabilen ücretsiz bir katmanı vardır. Daha büyük ekipler ve gelişmiş işbirliği için ücretli planlar sunulur.

Docs-as-code, CMS veya wiki'den nasıl farklıdır?

Wiki ve CMS içerikleri genellikle ayrı bir veritabanında saklar. Docs-as-code ise içeriği Git deposunda dosya olarak tutar. Böylece dokümanlar branch, pull request, review ve CI/CD süreçlerine dahil olur.

Geliştirici olmayanlar Git entegrasyonlu dokümanlara katkı verebilir mi?

Evet. Mintlify ve GitBook gibi araçlar Git'e commit atan web editörleri sunar. Böylece yazarlar ve ürün yöneticileri görsel arayüzle çalışırken mühendisler dosya tabanlı iş akışını sürdürebilir.

Sonuç

API dokümantasyonu API'den ayrı yaşadığında zamanla sapar. Git entegrasyonu bu sorunu, spesifikasyonu kaynak ve merge işlemini yayın tetikleyicisi yaparak azaltır.

Mintlify docs-as-code portalı için, Fern SDK ve doküman üretimi için, Redocly ise OpenAPI yönetimi için güçlü seçeneklerdir. Ancak dokümantasyonu güncel tutmanın en doğrudan yolu, onu ayrı bir yapıt olarak yönetmemektir.

Hepsi bir arada yaklaşımda Apidog, dokümanları, testleri, mock'ları ve API tasarımını aynı Git senkronize OpenAPI spesifikasyonundan üretir. Böylece her merge sonrası dokümantasyonunuz API sözleşmesiyle birlikte güncel kalır.

Git ile Çalışan En İyi API Araçları

Tobias Hoffmann — Thu, 04 Jun 2026 08:26:06 +0000

Kodunuz Git'te yaşar; API spesifikasyonlarınız, istek koleksiyonlarınız, belgeleriniz ve testleriniz çoğu zaman yaşamaz. Sonuç: GUI veya satıcı bulutunda duran API varlıkları koddan ayrılır, PR'lar eksik incelenir, dokümanlar eskir ve “benim makinemde çalışıyor” tipi API hataları üretime taşınır.

Apidog'u bugün deneyin

Çözüm, API varlıklarını da kod gibi yönetmektir: dosya olarak saklayın, çekme isteklerinde inceleyin, her özellik için dallandırın ve CI ile her gönderimde doğrulayın. Modern API araçları artık düz metin dosyaları okuyup yazabiliyor, GitHub veya GitLab ile senkronize olabiliyor ve ekibinizin mevcut review akışına uyabiliyor.

Bu kılavuz, 2026'da Git ile çalışan API araçlarını uygulama perspektifiyle gruplandırır: hepsi bir arada platformlar, istemciler, tasarım/spesifikasyon araçları, dokümantasyon ve CI testleri. Önce Apidog ile başlayacağız; ardından ekibiniz için sürüm kontrollü bir API yığını nasıl kuracağınızı adım adım ele alacağız. Spesifikasyonlarınızı depoya taşımaya başladıysanız, Git-yerel API iş akışı kılavuzu bu yazıyla birlikte okunabilir.

TL;DR: Git dostu API araçları

Kısa liste:

Apidog: Tasarım, test, dokümantasyon ve mock sunucuları tek bir OpenAPI kaynağına bağlamak isteyen ekipler için hepsi bir arada seçenek.
Bruno ve Insomnia: API isteklerini dosya olarak saklamak ve Git ile takip etmek isteyen geliştiriciler için güçlü istemciler.
Stoplight ve Redocly: OpenAPI tasarımı, linting ve spesifikasyon yönetimi için Git destekli araçlar.
Mintlify, Fern ve ReadMe: Depodan yayınlanan kod olarak dokümantasyon akışları için.
Newman, Step CI ve Schemathesis: API testlerini CI içinde çalıştırmak için.

Temel seçim kriteri basit: API varlıklarını yalnızca satıcı veritabanında değil, commit edilebilir dosyalar olarak saklayan araçları tercih edin.

API iş akışınız neden Git'te olmalı?

API spesifikasyonlarını ve testlerini Git'e almak sadece düzen meselesi değildir. Doğrudan hata önleme ve ekip içi görünürlük sağlar.

1. Tek doğruluk kaynağı oluşturursunuz

Spesifikasyon, testler ve belgeler kodla aynı depoda yaşadığında ikinci bir sistem senkronize etmek zorunda kalmazsınız.

Örnek repo yapısı:

repo/
  src/
  api/
    openapi.yaml
    tests/
      contract-tests.yaml
    docs/
      overview.md

Bir endpoint değiştiğinde aynı PR içinde şunlar birlikte güncellenir:

src/orders/controller.ts
api/openapi.yaml
api/tests/orders.yaml
api/docs/orders.md

2. API sözleşmesi review edilebilir hale gelir

Bir API sözleşmesi değişikliği, kod değişikliği kadar risklidir. Dosya olarak tutulduğunda ekip arkadaşınız satır satır yorum yapabilir.

Bu yaklaşım, kod olarak spesifikasyon modelinin temelidir.

3. Her özellik için dal açabilirsiniz

Yeni bir endpoint veya breaking change için ayrı dal kullanabilirsiniz:

git checkout -b feature/order-status

Sonra kod, OpenAPI tanımı, test ve doküman değişikliklerini aynı PR içinde birleştirirsiniz.

4. CI ile otomatik doğrulama yapabilirsiniz

OpenAPI dosyanız depodaysa her push'ta lint, validation ve contract test çalıştırabilirsiniz. Bu, bozuk sözleşmeleri üretime gitmeden yakalar. Hassas API dokümantasyonu için denetim izi de sağlar; bu konu API dokümantasyonu depo güvenliği açısından önemlidir.

“Git ile çalışmak” pratikte ne demek?

Bir aracın GitHub logosu göstermesi yeterli değildir. Gerçekten Git dostu bir API aracı şu özellikleri sağlamalıdır:

Dosya tabanlı depolama: YAML, JSON, Markdown veya belgelenmiş düz metin formatı kullanmalı.
Çift yönlü senkronizasyon: Araçta yapılan değişiklik depoya, depodaki değişiklik araca yansımalı.
Dal ve merge desteği: Farklı branch'ler arasında çalışırken veri modeli bozulmamalı.
CI çalıştırıcısı: Aynı test veya doğrulama komut satırından çalıştırılabilmeli.
Diff okunabilirliği: PR'daki değişiklikler insan tarafından incelenebilir olmalı.

Hepsi bir arada: Apidog

Apidog, API tasarımı, hata ayıklama, test, mock ve dokümantasyonu tek bir OpenAPI merkezli iş akışında birleştirir. Git ile senkronize çalışan spesifikasyon sayesinde ekip, API yaşam döngüsünü ayrı araçlara bölmeden sürüm kontrolüne alabilir.

Pratik akış şöyle görünür:

OpenAPI spesifikasyonunu depoya koyun.
Apidog'u bu depoya bağlayın.
Endpoint'i Apidog içinde tasarlayın veya düzenleyin.
Mock, test senaryosu ve dokümantasyonu aynı spesifikasyondan üretin.
Değişiklikleri branch üzerinden PR'a taşıyın.
CI'da testleri çalıştırın.

Apidog'un Git entegrasyonu ve senkronizasyonu, GitHub, GitLab ve self-hosted Git kurulumlarıyla bağlantı kurar. Spesifikasyon odaklı yaklaşımı detaylandırmak için spesifikasyon odaklı mod kılavuzuna bakabilirsiniz.

En iyi kullanım alanı: Tasarım, test, mock ve dokümantasyonu tek bir sürüm kontrollü API kaynağından yönetmek isteyen ekipler.

Git dostu API istemcileri: Bruno ve Insomnia

Sadece istek göndermek ve koleksiyonları Git'te saklamak istiyorsanız dosya tabanlı istemciler yeterli olabilir.

Bruno

Bruno, istekleri sahip olduğunuz bir klasörde .bru dosyaları olarak saklar. Zorunlu bulut senkronizasyonu yoktur; koleksiyon dosyaların kendisidir.

Örnek yaklaşım:

api-requests/
  orders/
    get-orders.bru
    create-order.bru
  users/
    get-user.bru

Bu yapı sayesinde istek değişiklikleri normal Git diff olarak görünür. Bruno'nun yaklaşımını Bruno istek odaklı vs. tasarım odaklı karşılaştırmasında ele aldık.

Insomnia

Insomnia, koleksiyonları ve ortamları Git Sync ile depoya bağlayabilir. Daha geleneksel ve görsel bir API istemcisi isteyen ekipler için uygundur. Başlangıç için Insomnia API test rehberi temel akışı gösterir.

En iyi kullanım alanı: API koleksiyonlarını depoda saklamak isteyen, ancak tüm yaşam döngüsünü tek platformda yönetmeye ihtiyaç duymayan geliştiriciler. Alternatifler için en iyi Postman alternatifleri listesine bakabilirsiniz.

API tasarım ve spesifikasyon araçları: Stoplight ve Redocly

Bu araçlar, OpenAPI dosyasını merkezi yapı olarak kabul eder ve Git tabanlı tasarım akışını destekler.

Stoplight

Stoplight, OpenAPI dosyasını görsel olarak düzenlemenizi sağlar. Depodaki spesifikasyonu okuyup yazabilir ve stil kurallarıyla tutarlılığı artırabilir.

Redocly

Redocly, OpenAPI yönetimi, linting, çok dosyalı spesifikasyon yapıları ve dokümantasyon üretimi tarafında güçlüdür. API-first ekipler için CI'a uygun kontroller sağlar.

Örnek CI fikri:

name: api-checks

on:
  pull_request:

jobs:
  lint-openapi:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Lint OpenAPI
        run: npx @redocly/cli lint api/openapi.yaml

Bu yaklaşım Git ile OpenAPI sürüm kontrolü modeline uyar. Spesifikasyonu sağlam tutmak için ayrıca OpenAPI doğrulayıcı kullanabilirsiniz.

En iyi kullanım alanı: API tasarım kurallarını wiki yerine CI içinde uygulamak isteyen ekipler.

Dokümantasyon: Mintlify, Fern ve ReadMe

Kod olarak dokümantasyon, API belgelerinin depodaki Markdown ve OpenAPI dosyalarından oluşturulmasıdır. Böylece dokümanlar API'den kopmaz.

Mintlify

Mintlify, Markdown ve OpenAPI dosyalarını depodan senkronize eder, değişikliklerde yeniden oluşturur ve branch preview akışlarını destekler.

Fern

Fern, tek bir spesifikasyondan dokümantasyon ve SDK üretmeye odaklanır. Böylece yayımlanan referans ile istemci kodu aynı kaynaktan türeyebilir.

ReadMe

ReadMe, Git'ten içerik senkronize edebilen geliştirici portalı sağlar. Özellikle herkese açık API portalları için uygundur.

Bu konuyu Git entegrasyonlu API belgeleri yazısında daha detaylı ele alıyoruz.

En iyi kullanım alanı: API dokümantasyonunun her merge sonrası otomatik güncellenmesini isteyen ekipler.

Test ve CI: Newman, Step CI ve Schemathesis

API testleri depoda yaşıyorsa CI içinde otomatik çalıştırılabilir.

Newman

Newman, Postman koleksiyonlarını komut satırından çalıştırır. Koleksiyon JSON dosyaları depoya commit edilirse CI'da kullanılabilir.

İlgili karşılaştırmalar:

Step CI

Step CI, YAML iş akışlarıyla API kontrolleri tanımlamanızı sağlar. Test tanımı kodun yanında yaşar.

Schemathesis

Schemathesis, OpenAPI spesifikasyonunu okuyarak property-based testler üretir. Spesifikasyondan doğan sözleşme ihlallerini yakalamak için kullanışlıdır.

Apidog da CLI çalıştırıcısı sunar; böylece senkronize spesifikasyona bağlı test senaryolarını aynı pipeline içinde çalıştırabilirsiniz.

En iyi kullanım alanı: Her PR'da API sözleşmesini otomatik doğrulamak isteyen ekipler.

Git dostu API araçları karşılaştırması

Araç	Kategori	Şu şekilde saklar	Git senkronizasyonu	CI çalıştırıcı
Apidog	Hepsi bir arada	OpenAPI + proje dosyaları	Evet (GitHub/GitLab/self-host)	Evet
Bruno	İstemci	`.bru` metin dosyaları	Evet (dosyalar koleksiyondur)	Evet
Insomnia	İstemci	Koleksiyon dosyaları	Evet (Git Sync)	Evet
Stoplight	Tasarım	OpenAPI dosyası	Evet	CLI aracılığıyla
Redocly	Tasarım/belgeler	OpenAPI + Markdown	Evet	Evet
Mintlify	Belgeler	Markdown + OpenAPI	Evet (çift yönlü)	Evet
Fern	Belgeler/SDK	Spec + yapılandırma	Evet	Evet
Newman	Test	Postman JSON	Depo aracılığıyla	Evet
Step CI	Test	YAML iş akışları	Evet	Evet

API iş akışınızı Git'e nasıl taşırsınız?

Her şeyi tek seferde dönüştürmek zorunda değilsiniz. Uygulanabilir bir geçiş planı:

1. OpenAPI spesifikasyonunu depoya koyun

Önce API sözleşmesini kodun yanına alın:

mkdir -p api
cp openapi.yaml api/openapi.yaml
git add api/openapi.yaml
git commit -m "Add OpenAPI specification"

Bu tek adım bile geçmiş, review ve rollback sağlar. Mekanik için OpenAPI spesifikasyonunu GitHub ile senkronize etme kılavuzuna bakabilirsiniz.

2. Git dostu aracı kanonik dosyaya bağlayın

Apidog, Bruno, Stoplight veya Redocly gibi aracı depodaki dosyaya yönlendirin. Amaç, aracın kendi kopyasını değil, depodaki dosyayı doğruluk kaynağı kabul etmesidir.

3. CI kontrolleri ekleyin

Başlangıç için minimum kontroller:

name: api-ci

on:
  pull_request:

jobs:
  validate-api:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Validate OpenAPI
        run: npx @redocly/cli lint api/openapi.yaml

Daha sonra contract test, mock sunucu testi veya Schemathesis gibi kontroller ekleyebilirsiniz.

4. API değişiklikleri için branch kullanın

Her API değişikliğini kod değişikliği gibi yönetin:

git checkout -b feature/add-order-status
# kod + openapi + test + docs değişiklikleri
git push origin feature/add-order-status

Bu yapı, Git-yerel API geliştirme yaklaşımının pratik karşılığıdır.

Örnek PR akışı: `status` alanı ekleme

Bir geliştiricinin orders endpoint'ine status alanı eklediğini düşünün.

1. Branch açılır

git checkout -b feature/order-status

2. OpenAPI sözleşmesi güncellenir

Örnek değişiklik:

Order:
  type: object
  properties:
    id:
      type: string
      example: ord_123
    status:
      type: string
      enum: [pending, paid, shipped, cancelled]
      example: paid

3. Test senaryosu eklenir

- name: order includes status
  request:
    method: GET
    url: /orders/ord_123
  expect:
    status: 200
    json:
      status: paid

4. Dokümantasyon aynı spesifikasyondan güncellenir

Eğer dokümantasyon OpenAPI'den üretiliyorsa manuel kopyalama gerekmez. Referans sayfası yeni alanı otomatik yansıtır.

5. PR açılır

Review eden kişi tek diff içinde şunları görür:

api/openapi.yaml
api/tests/orders.yaml
src/orders/*

6. CI merge kararını destekler

Pipeline:

OpenAPI lint çalıştırır.
Sözleşme testlerini yürütür.
Mock veya staging ortamına karşı istekleri kontrol eder.
Hata varsa merge'i durdurur.

Bu modelde ayrı GUI çalışma alanında unutulan değişiklik kalmaz; her şey tek PR içinde incelenir.

Git tabanlı API araçlarına geçerken yapılan yaygın hatalar

Hata 1: Export dosyasını sürüm kontrolü sanmak

Bir koleksiyonu ara sıra JSON olarak dışa aktarmak sürüm kontrolü değildir. Bu sadece snapshot'tır. Gerçek kaynak hâlâ bulut çalışma alanındaysa Git sadece yedek olur.

Hata 2: İki doğruluk kaynağı tutmak

Depoda OpenAPI dosyası, ayrı araçta elle güncellenen koleksiyon ve başka yerde dokümantasyon tutmak drift üretir. Mümkün olduğunca hepsini tek spesifikasyondan türetin.

Hata 3: CI eklememek

Spesifikasyonu Git'e koyup doğrulama çalıştırmamak eksik bir geçiştir. En azından lint ve schema validation ekleyin.

Hata 4: Devasa tek dosya spesifikasyonla devam etmek

Büyük openapi.yaml dosyaları merge conflict çıkarabilir. Gerekirse spesifikasyonu parçalara ayırın:

api/
  openapi.yaml
  paths/
    orders.yaml
    users.yaml
  components/
    schemas/
      Order.yaml
      User.yaml

Hata 5: Branch kuralı belirlememek

API değişiklikleri için açık bir kural koyun:

Her breaking change ayrı branch.
OpenAPI değişmeden endpoint merge edilmez.
Test eklenmeden yeni endpoint merge edilmez.
Dokümantasyon aynı PR'da güncellenir veya otomatik üretilir.

Git tabanlı API yığınızı Apidog ile test edin ve yayınlayın

Spesifikasyon Git'te yaşadığında, her branch'te onu kullanabilen bir araca ihtiyaç duyarsınız. Apidog, senkronize OpenAPI dosyasını okuyarak canlı isteklere, mock sunuculara, test senaryolarına ve dokümantasyona dönüştürür.

Uygulanabilir kurulum:

Repo spesifikasyonunu içe aktarın. İstekler ve testler elle sürdürülen kopyalardan değil, kanonik OpenAPI dosyasından türesin.
Ortamları tanımlayın. Aynı testleri local, staging ve production endpoint'lerine yönlendirin.
CLI'ı CI içinde çalıştırın. PR açıldığında contract testler otomatik çalışsın.
Belgeleri aynı spesifikasyondan üretin. Yayınlanan dokümantasyon tasarımdan geride kalmasın.
Branch bazlı değişiklikleri review edin. Sözleşme, test ve dokümantasyon aynı PR'da görünür olsun.

Bu, “GitHub entegrasyonu olan araç” ile “sürüm kontrollü API iş akışı için tasarlanmış araç” arasındaki farktır. İlk depo destekli projenizi bağlamak için Apidog'u indirin.

Sıkça Sorulan Sorular

Bir API aracının Git ile çalışması ne anlama gelir?

Aracın API varlıklarını commit edilebilir, branch'lenebilir ve review edilebilir dosyalar olarak saklaması anlamına gelir. Daha güçlü araçlar bu dosyaları depoyla çift yönlü senkronize eder ve CI için komut satırı çalıştırıcısı sağlar.

Postman Git dostu bir API aracı mıdır?

Postman bulut öncelikli çalışır. Koleksiyonlar genellikle Postman çalışma alanında yaşar; Git erişimi ise yerel dosya tabanlı çalışma yerine entegrasyonlarla sağlanır. Gerçek sürüm kontrolü isteyen ekipler Bruno gibi dosya tabanlı istemcilere veya Apidog gibi hepsi bir arada araçlara yönelebilir. Seçenekler için en iyi Postman alternatifleri listesine bakın.

OpenAPI spesifikasyonumu Git'te tutup yine de görsel araç kullanabilir miyim?

Evet. Apidog, Stoplight ve Redocly gibi araçlar bunun için kullanılır. OpenAPI dosyası depoda kanonik kalır; araç sadece düzenleme, test, dokümantasyon veya doğrulama arayüzü sağlar.

Bunun kod olarak dokümantasyondan farkı nedir?

Kod olarak dokümantasyon sadece belgeleri dosya tabanlı yönetir. Git tabanlı API iş akışı ise aynı modeli spesifikasyonlara, request koleksiyonlarına, mock'lara ve testlere genişletir.

Git dostu API araçları GitLab ve self-hosted Git ile çalışır mı?

Birçoğu çalışır. Apidog, GitHub, GitLab ve self-hosted örneklerle bağlantı kurar. Bruno gibi dosya tabanlı istemcilerde ise dosyalar düz metin olduğu için herhangi bir Git sağlayıcısıyla kullanılabilir.

Her şeyi bir kerede Git'e taşımam gerekiyor mu?

Hayır. En pratik sıra:

OpenAPI spesifikasyonunu depoya koyun.
Git dostu aracı bu dosyaya bağlayın.
CI doğrulaması ekleyin.
Testleri ve dokümantasyonu aynı kaynaktan üretin.
Her API değişikliğini branch + PR ile yönetin.

API araçlarını Git'e koymak ekibi yavaşlatır mı?

İlk kurulum biraz disiplin ister; ancak sonrasında review, otomatik test ve değişiklik geçmişi ekibi hızlandırır. “Bunu kim değiştirdi?” sorusu toplantı yerine Git geçmişiyle cevaplanır.

Bir araya getirmek

Git dostu API araçlarının ortak deseni nettir: API çalışmasını dosya olarak saklayın ve Git'in iyi yaptığı işleri kullanın. İhtiyaca göre seçim yapın:

Tüm API yaşam döngüsü için: Apidog
Dosya tabanlı istek istemcisi için: Bruno veya Insomnia
Spesifikasyon yönetimi için: Stoplight veya Redocly
Kod olarak dokümantasyon için: Mintlify, Fern veya ReadMe
CI testleri için: Newman, Step CI veya Schemathesis

Başlamak için OpenAPI spesifikasyonunuzu commit edin. Ardından Apidog'u depoya bağlayarak tasarım, test, dokümantasyon ve mock akışlarını ekibinizin zaten kullandığı Git review sürecine taşıyın.

En İyi 7 Git Tabanlı API İstemcisi 2026

Tobias Hoffmann — Thu, 04 Jun 2026 08:14:12 +0000

Çoğu API istemcisinde koleksiyonlar, ekibinizin tam olarak kontrol edemediği bir bulut çalışma alanında yaşar. Bu istekleri Git’te karşılaştıramaz, pull request içinde inceleyemez veya bir özellik dalı gibi dallandıramazsınız. İki kişi aynı koleksiyonu düzenlediğinde çoğu zaman “son kaydeden kazanır”. Git-yerel API istemcileri, istekleri deponuzda düz dosyalar olarak saklayarak bu problemi çözer.

Apidog'u bugün deneyin

Git-yerel veya Git dostu bir API istemcisi, koleksiyonları kaynak kod gibi ele alır: commit edilebilir, diff alınabilir, branch açılabilir, merge edilebilir ve review yapılabilir metin dosyaları. Böylece API koleksiyonunuz paylaşılan değiştirilebilir bir “blob” olmaktan çıkar; geçmişi olan, incelenebilir bir yapıta dönüşür. Aynı dosyalar CI’da da çalıştırılabildiği için ayrıca export alma adımı gerekmez.

Bu rehberde 2026 için öne çıkan Git-yerel ve Git dostu API istemcilerini pratik açıdan karşılaştırıyoruz. Hepsi bir arada seçenek olan Apidog ile başlayıp Bruno, Insomnia, Hoppscotch, Step CI, Hurl ve Postman’a bakacağız. Daha geniş iş akışı için Git-yerel API iş akışı rehberine de göz atabilirsiniz.

Özet: En iyi Git-yerel API istemcileri

Apidog: Hepsi bir arada en güçlü seçenek. İstekler, OpenAPI spesifikasyonu, testler, mock’lar ve dokümanlar tek projeden Git’e senkronize olur.
Bruno: En saf Git-yerel istemci. Koleksiyonlar bulut gerektirmeyen düz .bru dosyalarıdır.
Insomnia: Tanıdık bir istemciye Git Senkronizasyonu ekler.
Hoppscotch: Açık kaynaklı ve kendi kendine barındırılabilir seçenektir.
Step CI ve Hurl: Pipeline’larda çalışmak üzere tasarlanmış metin öncelikli araçlardır.
Postman: Güçlü bir ekosisteme sahip olsa da bulut önceliklidir; gerçek dosya tabanlı Git akışı için sınırlıdır.

Temel kontrol şudur: Koleksiyon deponuzda bir dosya değilse, gerçek anlamda sürüm kontrolünde değildir.

Bir API istemcisini “Git-yerel” yapan nedir?

Bir aracın GitHub entegrasyonundan bahsetmesi yeterli değildir. Git-yerel iş akışı için şu kriterleri kontrol edin:

Dosya tabanlı koleksiyonlar: İstekler okunabilir metin, YAML, JSON veya belgelenmiş bir format olarak saklanır.
Bulut bağımlılığı yok: Dosyalar koleksiyonun kendisidir; paylaşmak için satıcı bulutuna zorunlu olarak ihtiyaç duyulmaz.
Branch ve merge desteği: Her özellik için dal açabilir, çakışmaları kod dosyalarında olduğu gibi çözebilirsiniz.
CI’da çalıştırılabilirlik: Aynı dosyaları pipeline içinde çalıştıran bir CLI veya runner bulunur.
Çevrimdışı öncelikli kullanım: İstemci, dosyalar diskte olduğu sürece çalışabilir.

Basit bir Git-yerel API klasör yapısı şöyle olabilir:

repo/
  api/
    collections/
      users/
      payments/
    environments/
      local.env
      staging.env
  src/
  .github/
    workflows/
      api-tests.yml

Pratik hedef: API isteği, API kodu ve API testi aynı pull request içinde incelenebilmelidir.

En iyi Git-yerel ve Git dostu API istemcileri

1. Apidog: Deponuzda yaşayan hepsi bir arada çözüm

Apidog, yalnızca istekleri değil, API yaşam döngüsünün tamamını sürüm kontrolüne yaklaştırdığı için listenin başında yer alıyor. İstekler, OpenAPI spesifikasyonu, test senaryoları, mock tanımları ve dokümanlar aynı projede tutulur ve Git ile senkronize edilebilir.

Bir endpoint değiştiğinde sadece request değil; ilgili sözleşme, test ve dokümantasyon da aynı değişikliğin parçası olur. Bu, pull request review sürecini daha güvenilir hale getirir.

Git dostu bir istemci ile Git-yerel API iş akışı arasındaki fark burada ortaya çıkar. Sadece request-first bir istemci, isteklerinizi sürümlendirir. Apidog ise isteğin arkasındaki API sözleşmesini de iş akışına dahil eder.

Git entegrasyonu ve senkronizasyonu, GitHub, GitLab ve kendi kendine barındırılan Git sunucularıyla çalışır. Branch desteği sayesinde ekipler yeni API sürümlerini merge etmeden önce izole biçimde geliştirebilir. Request-first ve design-first yaklaşımlar arasındaki farkı görmek için Bruno: istek odaklı vs. tasarım odaklı karşılaştırmasına bakabilirsiniz.

Ne zaman seçilmeli?

API sözleşmesi, testleri ve dokümanları birlikte sürümlemek istiyorsanız.
API değişikliklerinin tek pull request içinde incelenmesini istiyorsanız.
Sadece koleksiyon değil, uçtan uca API yaşam döngüsü yönetimi istiyorsanız.

Kurumsal açıdan farkları görmek için Kurumsal yönetişim için Bruno vs Apidog yazısına bakabilirsiniz.

2. Bruno: En saf Git-yerel istemci

Bruno, Git-yerel API istemcisi denince akla gelen en net örneklerden biridir. Her istek, sizin kontrol ettiğiniz klasörde duran düz metin .bru dosyasıdır. Zorunlu bulut hesabı veya senkronizasyon sunucusu gerekmez.

Bu modelin avantajı basittir:

git checkout -b feature/new-user-endpoint
# Bruno ile isteği düzenle
git diff
git add api/users/create-user.bru
git commit -m "Add create user API request"
git push

İstek dosyası düz metin olduğu için ekip arkadaşınız pull request içinde hangi header’ın, body alanının veya assertion’ın değiştiğini görebilir.

Bruno tasarımı gereği çevrimdışı önceliklidir ve CI çalıştırmaları için CLI sunar. Tek gereksiniminiz “isteklerim depomdaki dosyalar olsun” ise Bruno çok temiz bir çözümdür.

Dezavantajı kapsamdır. Bruno odaklanmış bir istemcidir; dokümantasyon, mock servisler ve API tasarım süreci başka araçlarda yaşar. Ekiplerin bu sınırı ne zaman aştığını Hepsi bir arada Bruno alternatifi yazısında görebilirsiniz.

Ne zaman seçilmeli?

Bulutsuz, dosya öncelikli bir istemci istiyorsanız.
API yaşam döngüsünün tamamına değil, request koleksiyonlarına odaklanıyorsanız.
Git diff ve merge sizin için birincil gereksinimse.

3. Insomnia: Git Senkronizasyonlu tanıdık bir istemci

Insomnia, birçok geliştiricinin alışkın olduğu cilalı API istemcisi deneyimini korurken Git Senkronizasyonu ekler. Bu sayede koleksiyonlar ve ortamlar bir depoda saklanabilir, branch’lenebilir ve ekip içinde paylaşılabilir.

Insomnia, tamamen dosya-öncelikli araçlar kadar saf Git-yerel değildir; ancak mevcut Insomnia kullanıcıları için pratik bir geçiş yoludur. İstemci değiştirmeden daha iyi sürüm kontrolü isteyen ekipler için mantıklı bir orta noktadır.

İş akışını daha detaylı görmek için Insomnia API testi kılavuzu incelenebilir.

Ne zaman seçilmeli?

Insomnia arayüzünü zaten kullanıyorsanız.
Koleksiyonları depo destekli hale getirmek istiyorsanız.
Tam yaşam döngüsü platformuna geçmeden Git entegrasyonu istiyorsanız.

4. Hoppscotch: Açık kaynak ve kendi kendine barındırılabilir

Hoppscotch, hafif, açık kaynaklı ve kendi kendine barındırılabilir bir API istemcisidir. Özellikle her şeyi kendi altyapısında tutmak isteyen ekipler için uygundur.

Koleksiyonlar dosyalara aktarılabilir ve CLI ile CI ortamında çalıştırılabilir. Bu sayede açık kaynak ve şeffaf kalırken sürüm kontrollü bir API test akışına dahil edilebilir.

Kendi kendine barındırma, üçüncü taraf bulut risklerini azaltmak isteyen ekipler için önemli olabilir. Bu konu GitHub ihlali sonrası kendi kendine barındırılan API araçları yazısında daha detaylı ele alınmıştır.

Ne zaman seçilmeli?

Açık kaynaklı ve kendi kendine barındırılabilir bir istemci istiyorsanız.
Üçüncü taraf bulut bağımlılığını azaltmak istiyorsanız.
Basit, hafif ve maliyetsiz bir çözüm arıyorsanız.

5. Step CI ve Hurl: Pipeline’lar için metin öncelikli istemciler

Step CI ve Hurl, klasik GUI istemcilerden farklı çalışır. Burada birincil yapı test dosyasıdır; araçlar özellikle CI/CD içinde çalışmak üzere tasarlanmıştır.

Step CI, API kontrollerini YAML iş akışları olarak tanımlar. Bu dosyalar kodunuzun yanında durur ve her push işleminde çalıştırılabilir.

Örnek yapı:

version: "1.1"
name: API smoke test
env:
  host: https://api.example.com
tests:
  users:
    steps:
      - name: Get users
        http:
          url: ${{ env.host }}/users
          method: GET
          check:
            status: 200

Hurl ise istekleri ve assertion’ları düz metin formatında tanımlar:

GET https://api.example.com/users

HTTP 200
[Asserts]
jsonpath "$[0].id" exists

Her iki araç da varsayılan olarak Git-yereldir, çünkü dosyanın kendisi doğruluk kaynağıdır.

Ne zaman seçilmeli?

API kontrollerini kod olarak tanımlamak istiyorsanız.
GUI keşfinden çok CI doğrulamasına önem veriyorsanız.
Pipeline içinde küçük, hızlı ve metin tabanlı testler çalıştırmak istiyorsanız.

6. Postman: Yetenekli ama bulut öncelikli

Postman, API istemcisi ekosisteminde güçlü bir araçtır; ancak Git-yerel yaklaşım açısından kontrast olarak değerlendirilmelidir. Koleksiyonlar çoğunlukla bulut çalışma alanında yaşar. Git erişimi yerel dosya depolama yerine entegrasyonlar üzerinden sağlanır.

Bir Postman koleksiyonunu JSON olarak dışa aktarabilirsiniz; fakat bu genellikle anlık görüntüdür. Deponuzda yaşayan, sürekli değişen ve review edilen bir dosya ile aynı şey değildir.

Bu yüzden dosya tabanlı gerçek sürüm kontrolü isteyen ekipler için Postman çoğu zaman başlangıç noktasıdır, varış noktası değil. Alternatifler için en iyi Postman alternatifleri rehberine bakabilirsiniz.

Ne zaman seçilmeli?

Postman ekosistemi sizin için dosya tabanlı Git akışından daha önemliyse.
Bulut çalışma alanı modelini sorun olarak görmüyorsanız.
Ekip zaten Postman üzerinde standardize olduysa.

Git-yerel API istemcilerinin karşılaştırılması

İstemci	Koleksiyonları şu şekilde depolar	Bulut gerekli mi?	Dallandırma/Birleştirme	CI için CLI	Hepsi bir arada
Apidog	Proje dosyaları + OpenAPI	Hayır (Git senkronizasyonu)	Evet	Evet	Evet
Bruno	`.bru` metin dosyaları	Hayır	Evet	Evet	Hayır
Insomnia	Koleksiyon dosyaları (Git Senkronizasyonu)	İsteğe bağlı	Evet	Evet	Hayır
Hoppscotch	Dışa aktarılan dosyalar	Hayır (kendi kendine barındırılır)	Dosyalar aracılığıyla	Evet	Hayır
Step CI	YAML iş akışları	Hayır	Evet	Evet	Hayır
Hurl	Düz metin dosyaları	Hayır	Evet	Evet	Hayır
Postman	Bulut çalışma alanı	Evet	Sınırlı	Evet	Kısmi

Dosya tabanlı koleksiyonlar neden daha pratiktir?

Dosya tabanlı koleksiyonların değeri, API üzerinde birden fazla kişi çalışmaya başladığında ortaya çıkar.

1. Request değişikliği review edilebilir

Bir .bru, YAML, JSON veya proje dosyasındaki diff şunu gösterebilir:

- Authorization: Bearer {{old_token}}
+ Authorization: Bearer {{api_token}}

- POST /users
+ POST /v2/users

Bu değişiklik pull request içinde incelenebilir. Bulut çalışma alanında ise değişiklik çoğu zaman sonradan fark edilir.

2. Her özellik için branch açabilirsiniz

Yeni endpoint geliştirme akışı şöyle olabilir:

git checkout -b feature/add-payment-refund-api
# API kodunu değiştir
# API request/test dosyasını değiştir
git add src/ api/
git commit -m "Add refund API and request coverage"

Bu yaklaşım, kod olarak spesifikasyon modeliyle uyumludur.

3. Geçmiş Git tarafından tutulur

Kimin hangi endpoint’i, hangi header’ı veya hangi test assertion’ını değiştirdiği Git geçmişinden görülebilir. Ayrı bir audit log oluşturmanız gerekmez.

4. CI aynı dosyaları çalıştırır

Ekip tarafından düzenlenen dosyalar ile pipeline’ın çalıştırdığı dosyalar aynı olur. Bu, export alma ve daha sonra drift oluşması riskini azaltır.

Bulut istemcisinden Git-yerel istemciye geçiş

Postman gibi bulut öncelikli bir istemciden Git-yerel akışa geçiş genellikle adım adım yapılabilir.

1. Mevcut koleksiyonları dışa aktarın

İlk adım olarak mevcut koleksiyonları ve ortamları JSON olarak dışa aktarın. Bu dosyaları nihai kaynak olarak değil, geçiş anlık görüntüsü olarak düşünün.

2. Yeni istemciye içe aktarın

Bruno, Apidog, Insomnia ve Hoppscotch ortak koleksiyon formatlarını ve OpenAPI tanımlarını okuyabilir. Apidog, Postman koleksiyonlarını doğrudan içe aktarır; bu da geçiş süresini kısaltır.

3. Dosyaları depoya commit edin

İçe aktarılan koleksiyonu test ettiği servisin yanına koyun:

service-users/
  src/
  api/
    collections/
    environments/

Sonra commit edin:

git add api/
git commit -m "Add API collection to repository"

4. Gizli bilgileri dosyalardan çıkarın

API anahtarlarını, token’ları veya production credential’larını commit etmeyin. Dosyada yalnızca değişken adları kalsın:

Authorization: Bearer {{API_TOKEN}}

Gerçek değerleri ortam değişkenlerinden veya secret manager’dan okuyun. Bu konu için API anahtarı güvenliği notları doğrudan uygulanabilir.

5. CI adımı ekleyin

Kullandığınız aracın CLI runner’ını pipeline’a ekleyin. Örnek GitHub Actions yapısı:

name: API checks

on:
  pull_request:
  push:

jobs:
  api:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run API collection
        run: |
          echo "Buraya seçtiğiniz istemcinin CLI komutunu ekleyin"

Amaç, API koleksiyonunun sadece depoda durması değil, her push işleminde test edilmesidir.

6. Branch-per-change modelini benimseyin

API isteği değişikliğini kod değişikliği gibi ele alın:

Branch açın.
Request/test dosyasını değiştirin.
Pull request açın.
Diff’i inceleyin.
CI sonucunu kontrol edin.
Merge edin.

Git-yerel’e geçerken yapılan yaygın hatalar

Gizli bilgileri commit etmek

Canlı API anahtarını depoya push etmek en kritik hatalardan biridir. İlk günden itibaren secret yönetimi kullanın.

JSON export dosyasını sürüm kontrolü sanmak

Tek seferlik export bir yedektir. Bulutta düzenlemeye devam edip ara sıra export alıyorsanız gerçek Git-yerel iş akışı kurmamış olursunuz.

Tek devasa koleksiyon dosyası kullanmak

Büyük tek dosyalar merge conflict üretir ve diff okumayı zorlaştırır. İstekleri servis veya domain bazlı klasörlere ayırın.

api/
  users/
  billing/
  auth/
  notifications/

CLI çalıştırmamak

Dosyalar CI’da çalışmıyorsa Git-yerel akışın en büyük avantajını kaçırırsınız. Runner’ı erken ekleyin.

İsimlendirme kuralı olmaması

Klasör ve istek adları için standart belirleyin. Ekip büyüdükçe düzensiz koleksiyonlar review sürecini yavaşlatır.

İsteklerinizi Apidog ile Git’e taşıyın

Testleri, mock’ları ve dokümanları bırakmadan dosya tabanlı istekler istiyorsanız, hepsi bir arada bir çözüm daha pratiktir. Apidog bu akışı tek projede toplar:

Projeyi GitHub, GitLab veya kendi kendine barındırılan Git ile senkronize edin.
Her özellik için branch açın ve API değişikliğini merge öncesi izole geliştirin.
CLI’yı CI’da çalıştırın ve request değişikliklerini pull request sürecine dahil edin.
Aynı spesifikasyondan dokümanlar ve mock’lar oluşturun, böylece API sözleşmesi ile çıktıların drift etmesini azaltın.

Tek proje; isteği, sözleşmeyi, testi ve dokümanı birlikte tuttuğu için reviewer tüm API değişikliğini tek diff içinde görebilir. Koleksiyonlarınızı kodunuzla birlikte depoya taşımak için Apidog’u indirin.

Sıkça sorulan sorular

Git-yerel API istemcisi nedir?

Git-yerel API istemcisi, API koleksiyonlarını deponuzda düz dosyalar olarak saklayan istemcidir. Bu dosyalar commit edilebilir, diff alınabilir, branch’lenebilir, merge edilebilir ve pull request içinde review yapılabilir. Doğruluk kaynağı satıcı bulutundaki kayıt değil, depodaki dosyadır.

Postman Git-yerel bir istemci midir?

Hayır. Postman bulut önceliklidir. Koleksiyonlar kendi çalışma alanında yaşar ve Git erişimi sınırlı entegrasyonlarla sağlanır. JSON export alabilirsiniz; ancak bu, deponuzda yaşayan sürüm kontrollü dosya ile aynı şey değildir.

Bruno’ya en iyi Git-yerel alternatif nedir?

Sadece dosya tabanlı request koleksiyonları istiyorsanız Bruno çok güçlüdür. Bruno’nun dosya modelini testler, mock’lar ve dokümantasyonla birlikte tek sürümlenmiş projede istiyorsanız Apidog daha kapsamlı bir alternatiftir.

Git-yerel istemciler CI/CD’de çalışabilir mi?

Evet. Bruno, Hoppscotch, Step CI, Hurl ve Apidog komut satırı çalıştırıcıları sunar. Böylece ekibin düzenlediği aynı dosyalar her push veya pull request sırasında pipeline içinde çalıştırılabilir.

Bu istemciler çevrimdışı çalışır mı?

Dosya tabanlı olanlar çalışır. Bruno, Hurl ve Step CI yerel dosyalardan çalışır. Hoppscotch kendi kendine barındırılabilir. Apidog, projeyi yerel olarak kullanılabilir tutarken Git ile senkronize eder. Bulut öncelikli istemciler ise servis erişilebilirliğine daha bağımlıdır.

API isteklerini neden Git’te depolamalıyız?

Çünkü API sözleşmesi kod kadar kritiktir. İstekleri dosya olarak depolamak size review, geçmiş, branch, merge ve CI avantajı sağlar. Bu yaklaşım Git-yerel API geliştirme pratiğinin temelidir.

En Git-yerel API istemcisi hangisidir?

Bruno en saf Git-yerel istemcidir; çünkü her istek zorunlu bulut gerektirmeyen düz metin dosyasıdır. Apidog ise en eksiksiz seçenektir; çünkü isteklerle birlikte spesifikasyonu, testleri ve dokümanları da sürümlendirir.

Dosya tabanlı koleksiyonlar merge conflict üretir mi?

Evet, herhangi bir dosya gibi conflict oluşabilir. Ancak bu conflict düz metinde çözülebilir. Bulut çalışma alanında sessizce üzerine yazılan değişikliklere göre daha görünür ve yönetilebilirdir. İstekleri küçük klasörlere ayırmak conflict riskini azaltır.

Git-yerel istemciyi kendi kendine barındırılan Git sunucusuyla kullanabilir miyim?

Evet. Dosya tabanlı istemciler herhangi bir Git barındırıcısıyla çalışır. Apidog GitHub, GitLab ve kendi kendine barındırılan örneklerle bağlantı kurar. Hoppscotch gibi kendi kendine barındırılabilir istemciler de tüm akışı kendi altyapınızda tutmanıza yardımcı olur.

API koleksiyonunu depoda nerede saklamalıyım?

Genellikle test ettiği servisin yanında saklamak en pratiktir. Örneğin:

service-orders/
  src/
  api/
    collections/
    environments/

Paylaşılan koleksiyonlar için üst seviye api/ veya tests/ klasörü de kullanılabilir. Önemli olan, ekip büyümeden önce klasör yapısında anlaşmaktır.

Sonuç

Diff alamadığınız veya pull request içinde inceleyemediğiniz API koleksiyonları, ekip büyüdükçe risk üretir. Git-yerel istemciler bu koleksiyonları incelenebilir, branch’lenebilir ve CI’da çalıştırılabilir dosyalara dönüştürür.

Bruno en temiz saf Git-yerel istemcidir. Insomnia ve Hoppscotch güçlü Git dostu seçeneklerdir. Step CI ve Hurl pipeline öncelikli ekipler için uygundur. API istekleriyle birlikte spesifikasyon, test ve dokümantasyonu da tek sürüm kontrollü yapıda tutmak isteyen ekipler için hepsi bir arada yaklaşım daha güçlüdür.

Apidog’u deponuza bağlayarak koleksiyonlarınızı kodunuzla aynı review ve CI sürecine dahil edebilirsiniz. Başlamak için Apidog’u indirin.

GitHub Copilot Fiyatlandırma Değişiklikleri: Yapay Zeka Kredi Sistemi Açıklandı

Tobias Hoffmann — Thu, 04 Jun 2026 06:33:18 +0000

Kısaca: GitHub Copilot fiyatlandırma değişikliği 1 Haziran 2026'da başlıyor. GitHub Copilot, premium istek tabanlı faturalandırmadan GitHub AI Kredileri ile kullanım tabanlı faturalandırmaya geçiyor. Her premium etkileşimin bir istek birimi olarak sayılması yerine kullanım; girdi jetonları, çıktı jetonları ve önbelleğe alınmış jetonlar dahil olmak üzere jeton tüketimine göre hesaplanacak. Fiyatlandırma modele göre değişebilecek.

Apidog'u bugün deneyin

Temel Copilot plan fiyatları değişmiyor. Ancak ücretli kullanıcılar planlarına dahil olan kredileri aşarsa ek ödeme yapabilir. GitHub ayrıca geçiş öncesinde önizleme faturası deneyimi sunarak kullanıcıların ve yöneticilerin olası maliyetleri tahmin etmesini sağlayacak.

Bu rehber, GitHub Copilot fiyatlandırma değişikliğini uygulama açısından ele alır: ne değişiyor, kimler etkilenebilir, maliyetler nerede artabilir ve 1 Haziran 2026'dan önce hangi adımları atmanız gerekir.

GitHub Copilot Fiyatlandırma Değişikliği Nedir?

GitHub Copilot fiyatlandırma değişikliği, Copilot'un istek tabanlı faturalandırmadan kullanım tabanlı faturalandırmaya geçmesidir.

Eski modelde birçok ücretli Copilot etkileşimi premium istek birimi olarak ölçülüyordu. Bu yaklaşımda kısa bir sohbet sorusu ile uzun, çok adımlı aracılı bir kodlama oturumu faturalandırma açısından benzer görünebiliyordu.

1 Haziran 2026'dan itibaren premium istek birimlerinin yerini GitHub AI Kredileri alacak.

Yeni modelde:

Copilot kullanımı GitHub AI Kredileri tüketir.
Kredi tüketimi jeton kullanımına dayanır.
Jeton kullanımı girdi, çıktı ve önbelleğe alınmış jetonları içerir.
Farklı modeller kredileri farklı oranlarda tüketebilir.
Ücretli planlar, dahil edilen kredilerin üzerinde ek kullanım satın alabilir.
Business ve Enterprise planlarında krediler faturalandırma varlığı düzeyinde havuzlanır.
GitHub, 1 AI Kredisinin 0,01 ABD Dolarına eşit olduğunu belirtir.

Kısa versiyon: Copilot faturalandırması, API tabanlı yapay zeka servislerine daha çok benzeyecek. Ne kadar çok model çalışması isterseniz, o kadar çok kullanım tüketirsiniz.

Faturanıza Yansımadan Önce Jeton Tüketimini Ölçün

GitHub Copilot fiyatlandırma değişikliğiyle birlikte jeton görünürlüğü kritik hale geliyor. Özellikle aracı modları, çok dosyalı analizler ve uzun yeniden düzenleme görevleri için maliyet tahmini yapmak yerine önce ölçüm yapmanız gerekir.

Gerçek kullanımı incelemek için bir AI agent debugger kullanabilirsiniz. Apidog'un Yapay Zeka Aracı Hata Ayıklayıcısı gibi araçlar, aracı oturumlarında neler olduğunu daha görünür hale getirir:

Girdi jetonları: Her istemin ne kadar bağlam gönderdiğini görürsünüz.
Çıktı jetonları: Yanıtların uzunluğunu ve gereksiz ayrıntıları takip edersiniz.
Araç çağrı zincirleri: MCP araç çağrılarını, beceri yürütmelerini ve jeton maliyetlerini izlersiniz.
Oturum metrikleri: Tur sayısı, adım sayısı, yanıt süresi ve oturum başına tahmini maliyeti karşılaştırırsınız.

Pratik optimizasyon akışı:

Tipik bir aracılı görevi seçin: Bu modülü yeniden düzenle ve testleri güncelle
Görevi hata ayıklayıcıda çalıştırın.
Her adımda girdi ve çıktı jetonlarını kontrol edin.
Gereksiz bağlamı bulun:
- Fazla dosya mı gönderiliyor?
- Gereksiz günlükler mi ekleniyor?
- Kısa yanıt yeterliyken uzun açıklamalar mı üretiliyor?
İstemi daraltın ve tekrar çalıştırın.
Aynı görevi farklı modellerle karşılaştırarak maliyet/fayda dengesini inceleyin.

Eski ve Yeni Model Karşılaştırması

GitHub Copilot fiyatlandırma değişikliğindeki ana tarih 1 Haziran 2026.

Alan	1 Haziran 2026 Öncesi	1 Haziran 2026'dan İtibaren
Faturalandırma birimi	Premium istek birimleri	GitHub AI Kredileri
Kullanım esası	İstekler / etkileşimler	Jeton tüketimi
Maliyet sürücüleri	Premium istek sayısı, model çarpanları	Girdi jetonları, çıktı jetonları, önbelleğe alınmış jetonlar, model fiyatlandırması
Yoğun aracılı görevler	Daha küçük isteklere benzer sayılabilir	Daha fazla jeton nedeniyle daha fazla kredi tüketebilir
Temel plan fiyatları	Mevcut plan fiyatlandırması	GitHub, temel plan fiyatlandırmasının değişmediğini söylüyor
Ek kullanım	İstek modeline göre	Ücretli planlar ek kullanım satın alabilir
Yönetici görünürlüğü	Mevcut faturalandırma araçları	Geçiş öncesi önizleme faturası ve kullanım görünürlüğü

Aylık abonelik fiyatınız aynı kalsa bile efektif maliyetiniz değişebilir. Çünkü artık önemli olan sadece Copilot kullanıp kullanmadığınız değil, Copilot'u nasıl kullandığınız olacak.

GitHub Copilot Fiyatlandırmasını Neden Değiştiriyor?

GitHub'ın açıklaması net: Copilot'u çalıştırmanın maliyeti arttı.

Copilot artık yalnızca editör içi otomatik tamamlama aracı değil. Şunları da destekliyor:

Sohbet
Birden fazla model
Aracılı iş akışları
Depo düzeyinde görevler
CLI yardımı
Daha uzun kodlama oturumları

Örneğin şu iki görev aynı maliyete sahip değildir:

Bu fonksiyonu açıkla.

Bu servisi yeniden düzenle, testleri güncelle, hata günlüklerini incele ve depo genelinde değişiklikler öner.

İlk görev küçük bir bağlam ve kısa bir çıktı gerektirir. İkincisi birden fazla dosya, test çıktısı, hata günlüğü, araç çağrısı ve uzun model çıktısı gerektirebilir.

Kullanım tabanlı faturalandırma, fiyatı gerçek yapay zeka iş yüküne yaklaştırmayı amaçlar.

Bilmeniz Gereken Temel Terimler

GitHub Copilot fiyatlandırma değişikliğini anlamak için dört kavramı bilmeniz gerekir.

Premium İstek Birimleri

Premium istek birimleri, ücretli Copilot etkileşimlerini ölçmenin eski yoluydu.

Geliştiriciler açısından anlaşılması kolaydı çünkü “kaç istek kullandım?” şeklinde düşünülebiliyordu. Ancak her istek aynı maliyete sahip değildir.

Kısa bir soru ile uzun bir aracılı yeniden düzenleme görevi aynı model iş yükünü oluşturmaz.

GitHub AI Kredileri

GitHub AI Kredileri yeni faturalandırma birimidir.

1 Haziran 2026'dan itibaren Copilot kullanımı premium istek birimleri yerine AI Kredileri tüketecek. GitHub, 1 AI Kredisinin 0,01 ABD Dolarına eşit olduğunu belirtir.

Her Copilot planı aylık bir AI Kredisi tahsisi içerir. Dahil edilen kredi miktarı aşılırsa ek kullanım maliyeti oluşabilir.

Girdi Jetonları

Girdi jetonları, modele gönderilen içeriktir.

Copilot için girdi jetonları şunları içerebilir:

İsteminiz
Seçilen kod
Açık dosyalar
İlgili depo bağlamı
Hata mesajları
Test çıktıları
Sohbete yapıştırılan API şemaları veya belgeler
Aracı talimatları

Daha fazla bağlam, daha fazla girdi jetonu demektir.

Çıktı Jetonları

Çıktı jetonları, modelin ürettiği içeriktir.

Örnekler:

Kod önerileri
Sohbet açıklamaları
Test senaryoları
Yeniden düzenleme planları
Oluşturulan dosyalar
Hata ayıklama adımları
API istemci kodu
Belge taslakları

Copilot'un yanıtı ne kadar uzun ve ayrıntılıysa, o kadar fazla çıktı jetonu kullanılır.

Önbelleğe Alınmış Jetonlar

Önbelleğe alınmış jetonlar, modelin yeniden kullandığı veya depoladığı bağlamla ilgilidir.

Önbelleğe alma tekrarlanan bağlamı daha verimli hale getirebilir. Ancak GitHub'ın fiyatlandırma yapısında girdi, çıktı ve önbelleğe alınmış jetonlar modele bağlı olarak farklı değerlendirilebilir.

Maliyetler Nerede Artabilir?

Bu değişiklik her kullanıcıyı aynı şekilde etkilemez.

Bazı geliştiriciler için dahil edilen AI Kredileri yeterli olabilir. Ancak Copilot'u yoğun şekilde aracı modunda kullanan ekipler için yeni maliyet yönetimi ihtiyacı doğabilir.

Daha Düşük Riskli Kullanım

Aşağıdaki kullanım türlerinde büyük maliyet baskısı görme olasılığınız daha düşüktür:

Hafif kod tamamlama
Kısa sohbet soruları
Küçük kod açıklamaları
Ara sıra hata düzeltmeleri
Sınırlı model değiştirme
Minimum depo bağlamı

Bu etkileşimler de kredi tüketir, ancak uzun ve yoğun aracı oturumları kadar yüksek tüketim oluşturma olasılıkları daha düşüktür.

Daha Yüksek Riskli Kullanım

Aşağıdaki kullanım türlerinde maliyeti daha yakından izlemeniz gerekir:

Aracı modu
Depo genelinde yeniden düzenlemeler
Çok adımlı hata ayıklama oturumları
Büyük dosya analizi
Birçok dosyada test üretimi
Uzun hata günlükleriyle tekrarlanan istemler
Karmaşık mimari planlama
Basit görevler için premium model kullanımı
Uzun CLI veya bulut aracı oturumları

Bu iş akışları daha fazla girdi ve çıktı jetonu üretir. Jeton tabanlı faturalandırmada bu doğrudan maliyete yansıyabilir.

Örnek: Basit Sohbet ve Aracılı Yeniden Düzenleme

Değişiklikten Önce

Bir geliştirici şunu sorar:

Bu fonksiyonu açıkla.

Başka bir geliştirici şunu ister:

Bu hizmeti yeniden düzenle, testleri güncelle, hata günlüklerini incele ve depo genelinde değişiklikler öner.

İstek odaklı modelde bu iki etkileşim, gerçek hesaplama maliyetleri farklı olsa da faturalandırmada daha benzer görünebilirdi.

Değişiklikten Sonra

İlk istek şunları kullanabilir:

Küçük bir istem
Seçili bir fonksiyon
Kısa bir açıklama

İkinci istek şunları kullanabilir:

Birden fazla dosya
Depo bağlamı
Uzun akıl yürütme adımları
Oluşturulan kod
Test değişiklikleri
Takip eden düzeltmeler
Daha büyük model çıktısı

Sonuç: İkinci görev daha fazla jeton ve daha fazla AI Kredisi tüketir.

Bu Bir Fiyat Artışı mı?

Cevap: Copilot'u nasıl kullandığınıza bağlı.

GitHub, temel plan fiyatlandırmasının değişmediğini söylüyor. Yani abonelik etiket fiyatı aynı kalabilir.

Ancak kullanım tabanlı faturalandırma, dahil edilen AI Kredilerini aşan kullanıcılar için etkili bir maliyet artışı gibi hissedilebilir. Özellikle şu faktörler tüketimi artırabilir:

Yoğun aracı kullanımı
Uzun istemler
Büyük bağlam pencereleri
Premium model seçimi
Çok adımlı kod üretimi ve test döngüleri

Bu yüzden doğru soru şu değildir:

Aylık plan fiyatı değişti mi?

Daha iyi soru şudur:

Dahil edilen AI Kredileri, ekibimizin gerçek Copilot kullanımını karşılıyor mu?

Copilot Maliyetlerini Kontrol Etmek İçin Pratik Adımlar

Copilot'u bırakmadan yeni modele uyum sağlamak için aşağıdaki adımları uygulayabilirsiniz.

1. İstemleri Spesifik Tutun

Belirsiz istemler daha fazla bağlam ve daha uzun yanıt üretir.

Verimsiz örnek:

Bu hizmetin tamamını incele ve iyileştir.

Daha iyi örnek:

customerId null olduğunda createInvoice'ın neden 500 döndürdüğünü bul.
Minimal bir düzeltme ve bir regresyon testi öner.

2. Tam Dosyaları Tekrar Tekrar Yapıştırmayın

Copilot zaten yeterli bağlama sahipse aynı dosyayı tekrar göndermeyin.

Sorun tek bir fonksiyondaysa, istemi o fonksiyona odaklayın:

Sadece calculateTotal fonksiyonundaki yuvarlama hatasını incele.
Dosyanın geri kalanı için öneri verme.

3. Gelişmiş Modelleri Bilinçli Kullanın

Daha yetenekli modeller karmaşık görevler için değerli olabilir. Ancak basit sözdizimi soruları veya küçük açıklamalar için kullanıldığında gereksiz kredi tüketebilir.

Basit görev:

Bu TypeScript tip hatasını açıkla.

Karmaşık görev:

Bu ödeme akışında idempotency sorunlarını bul.
İlgili test senaryolarını ve olası yarış durumlarını listele.

İkinci görev daha gelişmiş model kullanımını daha iyi haklı çıkarabilir.

4. Aracılı İşleri Küçük Parçalara Bölün

Tek büyük görev yerine aşamalı ilerleyin.

Büyük ve pahalı olabilecek istem:

Tüm faturalandırma modülünü yeniden düzenle ve tüm testleri güncelle.

Daha kontrollü başlangıç:

Önce fatura hesaplamasında yer alan dosyaları belirle.
Henüz kodu değiştirme.

Sonra ayrı adımlarla ilerleyin:

Sadece invoiceCalculator.ts dosyasındaki tekrar eden mantığı çıkar.
Testleri henüz değiştirme.

Şimdi sadece bu değişiklik için gerekli regresyon testlerini öner.

Bu yaklaşım hem kontrolü artırır hem de gereksiz model çalışmasını azaltabilir.

5. Çıktıları Copilot Dışında Doğrulayın

Copilot kod üretebilir, ancak her doğrulama adımı yeni ve uzun bir Copilot oturumu olmak zorunda değildir.

API'ler için istek göndermek, testleri çalıştırmak, yanıtları doğrulamak ve davranışı belgelemek üzere Apidog gibi araçlar kullanabilirsiniz. Böylece geri bildirim döngüsü yalnızca yapay zeka yanıtlarına değil, gerçek API sonuçlarına dayanır.

Topluluk Endişeleri

Geliştiricilerin GitHub Copilot fiyatlandırma değişikliğine tepkisi muhtemelen karışık olacak.

Bazı kullanıcılar bunu makul bulabilir. Aracılı yapay zeka kodlaması pahalıdır ve kullanım tabanlı faturalandırma yapay zeka platformlarında yaygındır.

Diğer kullanıcılar öngörülemeyen maliyetlerden endişe duyabilir. Bu endişe geçerlidir. Copilot, birçok geliştirici için basit bir abonelik olarak konumlanmıştı. Kullanım artık jetonlara, modellere ve önbelleğe alınmış bağlama bağlı hale geldiğinde maliyeti tahmin etmek zorlaşabilir.

En yaygın sorular şunlar olacaktır:

Kredilerim bitecek mi?
Ekibimin faturası öngörülemez hale gelecek mi?
Aracılı kodlama çok pahalı hale gelecek mi?
Geliştiriciler fazla harcama korkusuyla Copilot kullanmaktan kaçınacak mı?
Yöneticiler yapay zeka kullanımını fazla mı kısıtlayacak?

Bu soruların pratik cevabı şeffaflıktır:

Önizleme faturalarını takip edin.
Kullanım panolarını inceleyin.
Harcama limitleri belirleyin.
Ekip içi model kullanım kuralları oluşturun.
Büyük aracı görevleri için ölçüm yapın.
Gereksiz bağlam göndermeyi azaltın.

1 Haziran 2026'dan Önce Kontrol Listesi

Kurumsal veya ekip düzeyinde Copilot kullanıyorsanız geçişten önce şu adımları uygulayın:

[ ] Yeni GitHub AI Kredisi modelini inceleyin.
[ ] Planınıza dahil olan kredi miktarını kontrol edin.
[ ] Önizleme faturasını takip edin.
[ ] En yoğun Copilot iş akışlarını belirleyin.
[ ] Aracı mod, premium model ve depo bağlamı kullanımı için kurallar oluşturun.
[ ] Büyük görevleri daha küçük adımlara bölün.
[ ] Ekip içinde örnek istem şablonları paylaşın.
[ ] API spesifikasyonlarını, testlerini ve belgelerini Apidog gibi araçlarda yapılandırılmış tutun.
[ ] Copilot'u gerçek geliştirme kaldıracı yarattığı yerlerde kullanın.

Sonuç

GitHub Copilot fiyatlandırma değişikliği, geliştiricilerin Copilot kullanımını nasıl optimize ettiğini değiştiriyor.

Eski modelde düşünce yapısı basitti:

Bir istek kullanıyorum.

Yeni modelde daha fazla değişken var:

Ne kadar bağlam gönderiyorum?
Ne kadar çıktı üretiyorum?
Hangi modeli kullanıyorum?
Bu görev harcanan kredilere değer mi?

Bu değişiklik Copilot'u daha az kullanışlı yapmaz. Copilot'u diğer bulut ve yapay zeka altyapılarına daha çok benzetir: güçlü, ölçeklenebilir ve yönetilmesi gereken bir araç.

1 Haziran 2026'ya kadar en iyi hazırlanan ekipler, Copilot'u tamamen kısıtlayanlar değil; onu daha ölçülü, görünür ve amaç odaklı kullananlar olacak.

2026'da En İyi 10 OpenRouter Alternatifi

Tobias Hoffmann — Thu, 04 Jun 2026 06:11:38 +0000

OpenRouter, yüzlerce modele tek API anahtarıyla erişmeyi kolaylaştırır; ancak kredi yükleme başına %5,5 ücret, $0,80 minimum ücret ve ayda 1 milyon BYOK isteğini aşınca eklenen %5 yönlendirme ücreti, üretim trafiğinde maliyeti artırabilir. Bu rehberde, OpenAI uyumlu API formatını koruyarak daha düşük maliyet, daha iyi yönlendirme kontrolü veya kendi kendine barındırma isteyen ekipler için 2026’daki en iyi OpenRouter alternatiflerini pratik geçiş adımlarıyla karşılaştırıyoruz.

Apidog'u bugün deneyin

OpenRouter alternatifi seçerken hedef basit olmalı: mevcut kodu yeniden yazmadan base_url, api_key ve model adlarını değiştirerek çalışmaya devam etmek. Aşağıdaki araçların tamamı OpenAI API formatını destekler; bu yüzden geçiş çoğu zaman yapılandırma değişikliği ve test sürecinden ibarettir.

💡Bir ağ geçidine geçmeden önce gecikme, streaming davranışı, token muhasebesi ve hata formatlarını Apidog’da test edin. Aynı isteği farklı sağlayıcılara göndererek gerçek maliyeti ve performansı yan yana doğrulayabilirsiniz.

TL;DR: 2026’daki en iyi OpenRouter alternatifleri

Hypereal AI: Genel olarak en güçlü seçenek. 1.000+ metin, görsel ve video modeli için tek OpenAI uyumlu API, resmi oranların altında fiyatlar ve Claude/GPT odaklı kodlama planı.
Blackmagic AI: Ön ödemeli LLM indirimleri için güçlü seçenek. 13+ sağlayıcıda tek bakiye ve liste fiyatlarında %48-74 indirim.
Requesty, Portkey, Together AI, Groq, Fireworks AI, LiteLLM, Cloudflare AI Gateway ve Eden AI: Akıllı yönlendirme, gözlemlenebilirlik, açık model çıkarımı, düşük gecikme, kendi kendine barındırma ve çok modaliteli kullanım senaryoları için diğer seçenekler.

Kısa karar ağacı:

Kodlama ajanlarında Claude/GPT maliyetini düşürmek istiyorsanız: Hypereal AI
Ön ödemeli indirim ve çok sağlayıcılı LLM erişimi istiyorsanız: Blackmagic AI
Açık modellerde ham çıkarım maliyeti ve hız istiyorsanız: Groq veya Together AI
Platform ücreti istemiyor ve kontrolü elde tutmak istiyorsanız: LiteLLM
Mevcut sağlayıcılarınızın önüne gözlemlenebilirlik katmanı koymak istiyorsanız: Cloudflare AI Gateway

Neden bir OpenRouter alternatifi aramalı?

OpenRouter güçlü bir üründür: tek anahtar, tek faturalama ilişkisi ve yüzlerce modele tek katalogdan erişim sağlar. Ancak üretim ortamında şu noktalar maliyet ve kontrol açısından önem kazanır.

1. Ücretler ölçekte büyür

OpenRouter, sağlayıcı fiyatlandırmasını geçirir; kredi satın aldığınızda %5,5 ücret ve $0,80 minimum ücret uygular. $5’lık küçük bir yüklemede bu minimum ücret tek başına yaklaşık %16 ek maliyet oluşturur.

OpenRouter fiyatlandırma sayfası bu yapıyı açıklar. OpenRouter SSS ise BYOK için şu koşulu belirtir: her ay ilk 1 milyon BYOK isteği ücretsizdir; sonrasında her istek, sağlayıcıdaki aynı çağrının maliyetinin %5’i kadar ücretlendirilir.

Bu tutarlar küçük başlayabilir; ancak yüksek trafik altında her token’a eklenen sürekli bir maliyet kalemine dönüşür.

2. Liste fiyatı ödemek her zaman en ucuz yol değildir

Geçişli fiyatlandırma ilk bakışta adil görünür. Ancak bazı toplayıcılar sağlayıcıların yayınladığı resmi fiyatların altında fiyat sunabilir. Token başına maliyeti düşürmek istiyorsanız, liste fiyatı + platform ücreti her zaman en iyi seçenek değildir.

Bu nedenle Hypereal ve Blackmagic gibi ağ geçitleri, indirimli fiyatlama ile öne çıkar. Benzer maliyet baskısı, 2026 Çin LLM fiyat savaşı gibi daha geniş piyasa eğilimlerinde de görülür.

3. Yönlendirme her zaman şeffaf olmayabilir

Aynı model birden fazla sağlayıcıdan sunulduğunda, isteğin hangi arka uçta çalışacağını her zaman siz belirleyemeyebilirsiniz. Bu durum şu farklara yol açabilir:

Gecikme süresi
Yanıt kalitesi
Hata oranı
Streaming davranışı
Token muhasebesi

Gecikme bütçesi olan ekipler, yönlendirme kararını kendi kontrolünde tutmak ister.

4. Küçük yüklemeler ve BYOK faturaları sürpriz yaratabilir

Ekiplerin sık karşılaştığı iki sorun:

Test aşamasında küçük bakiyeleri hızlı tüketen $0,80 minimum ücret
Trafik ayda 1 milyon BYOK isteğini geçtiğinde devreye giren %5 ek ücret

Eğer aracı token maliyetlerini düşürmeye çalışıyorsanız, bu sızıntıları kapatmak önemlidir.

İyi bir OpenRouter alternatifi nasıl seçilir?

Bir alternatifi değerlendirirken aşağıdaki kontrol listesini kullanın:

OpenAI uyumlu API: Geçiş, kodu yeniden yazmak yerine base_url değişimiyle yapılabilmeli.
Geniş model kapsamı: Metin, görsel ve video gibi modaliteleri desteklemesi avantaj sağlar.
Gerçek maliyet avantajı: Sadece kolaylık değil, resmi oranlara göre tasarruf sunmalı.
Güvenilirlik: Sağlayıcı kesintilerinde fallback veya akıllı yönlendirme sunmalı.
Faturalandırma kontrolleri: Anahtar başına limit, kullanım günlükleri ve bütçe takibi sağlamalı.
Gizlilik ve uyumluluk: Üretim verileri için denetlenebilir bir güvenlik duruşu olmalı.

2026’daki en iyi 10 OpenRouter alternatifi

1. Hypereal AI: daha ucuz modeller için en iyi hepsi bir arada ağ geçidi

Hypereal AI, bu listedeki en güçlü genel seçeneklerden biridir. Tek OpenAI uyumlu API ile 20+ sağlayıcıdan 1.000+ modele erişim sağlar. Kapsam yalnızca metinle sınırlı değildir; görsel ve video modellerini de aynı API üzerinden çağırabilirsiniz.

Örnek kullanım senaryoları:

Claude Opus 4.7 veya Gemini 3.5 ile kodlama ajanı çalıştırmak
DeepSeek V3.2 gibi metin modellerini denemek
Flux 2 Max ile görsel üretmek
Veo 3.1 veya Sora 2 ile video üretim akışlarını test etmek

Fiyatlandırma kredi tabanlıdır: 100 kredi = 1 ABD Doları. Kullanım kadar ödeme yapılır; abonelik gerekmez. Ücretsiz katmanda dakikada 60 istek bulunur. Ücretli katmanlar 10 ABD Doları’ndan 1.000 ABD Doları+ seviyesine kadar ölçeklenir.

Hypereal’in öne çıkan noktaları:

OpenAI Chat Completions ve görsel API’larıyla uyumlu yapı
Tek hesapla metin, görsel ve video modeli kullanımı
Akıllı yönlendirme
Arka uç sorunlarında yaklaşık 240 ms içinde hata toleransı
Canlı panoda bildirilen %99,98 çalışma süresi ve 312 ms p50 gecikme
SSO ve denetim günlükleri gibi ekip özellikleri

Geliştiriciler için en önemli özelliklerden biri kodlama planıdır. Bu plan, ön ödemeli kredi paketleri ve paket boyutuna göre artan kullanım çarpanları kullanır. Çarpan, 10 dolarlık pakette 4,4 kata; 1.000 dolarlık pakette 7,7 kata kadar çıkar.

Bu yapı özellikle şu araçlarla çalışan ekipler için uygundur:

Claude Code
Cursor
Cline
Aider
Continue.dev
OpenCode
OpenAI veya Anthropic SDK uyumlu araçlar

Bir Claude Agent SDK kurulumu yapıyorsanız veya Claude Opus 4.8 fiyatlandırmasını izliyorsanız, bu maliyet farkını test etmeye değer.

En iyisi: Metin, görsel ve video için tek fatura isteyen ekipler; Claude/GPT çağrılarını daha ucuza çalıştırmak isteyen kodlama atölyeleri; SSO ve denetim günlüklerine ihtiyaç duyan organizasyonlar.

Dikkat edilmesi gerekenler: Başlıktaki kodlama indirimleri desteklenen belirli modellere uygulanır. Geçmeden önce kendi model listenizin fiyatını doğrulayın.

2. Blackmagic AI: LLM çalışmaları için en iyi ön ödemeli indirimler

Blackmagic AI, OpenRouter benzeri deneyimi ön ödemeli kredi ve indirimli fiyatlama ile sunar. OpenAI uyumlu rotalar, sohbet alanı, API anahtarları, model kataloğu, kullanım günlükleri ve faturalandırma kontrolleri sağlar.

OpenRouter’ın kullanım modelini seviyor ama ücret yapısını azaltmak istiyorsanız, Blackmagic yakın bir alternatiftir.

Desteklenen sağlayıcı kapsamı şunları içerir:

OpenAI
Anthropic
Google Gemini
Meta
Mistral
xAI / Grok
DeepSeek
Qwen
Black Forest Labs / Flux
Moonshot AI
Cohere
Perplexity
Stability AI

Blackmagic’in iddiasına göre fiyatlar resmi liste fiyatlarının %48-74 altındadır. Örnekler:

GPT-5.5: milyon token başına 1.32 dolar giriş, 7.92 dolar çıkış
Claude Opus 4.8: milyon token başına 1.76 dolar giriş, 8.81 dolar çıkış
Claude Sonnet 4.6: milyon token başına 1.06 dolar giriş, 5.28 dolar çıkış

Faturalandırma ön ödemelidir. Abonelik veya aylık ücret yoktur. 10 dolar veya daha fazla yükleme yapılabilir; yüklemeler 9.99 dolardan 499.99 dolara kadar değişir. Her API anahtarına aylık harcama limiti atanabilir.

OpenAI uyumluluğu şu rotaları kapsar:

/chat/completions
/images/generations
/completions
/models

Bu nedenle çoğu SDK’da geçiş, base_url ve api_key değişimiyle yapılır.

En iyisi: OpenRouter benzeri tek bakiye ve çok sağlayıcılı deneyimi daha derin indirimlerle isteyen geliştiriciler.

Dikkat edilmesi gerekenler: Video yerine ağırlıklı olarak metin ve görsel modellere odaklanır.

3. Requesty: maliyet optimizasyonu ile akıllı yönlendirme

Requesty, maliyet odaklı yönlendirme isteyen ekipler için uygundur. Tek OpenAI uyumlu uç nokta arkasında 300+ model sunar ve şu özellikleri ekler:

Otomatik fallback
Önbellekleme
Harcama analizi
Sağlayıcı hata toleransı
Maliyet odaklı panolar

En iyisi: OpenRouter’ın yönlendirme yaklaşımını beğenen ancak daha sıkı maliyet kontrolleri ve hata toleransı isteyen ekipler.

4. Portkey: gözlemlenebilirlik ile kurumsal yapay zeka ağ geçidi

Portkey, model çeşitliliğinden çok yönetim, izleme ve güvenlik isteyen ekipler için tasarlanmıştır. Açık kaynaklı ağ geçidi çekirdeği ve barındırılan kontrol paneli sunar.

Öne çıkan özellikler:

Sanal API anahtarları
Güvenlik önlemleri
Semantik önbellekleme
Yeniden denemeler
Fallback
200+ modelde ayrıntılı izleme
Ekip bazlı maliyet ve kullanım görünürlüğü

En iyisi: “Kim hangi modeli çağırdı, ne kadar harcadı ve bunu nasıl kanıtlarız?” sorusuna yanıt arayan üretim ekipleri.

5. Together AI: açık modeller için hızlı çıkarım

Together AI, Llama, Qwen, DeepSeek ve Mixtral gibi açık ağırlıklı modeller için çıkarım bulutudur. OpenAI uyumlu API arkasında 200+ model sunar.

Kullanabileceğiniz başlıca yetenekler:

Açık model çıkarımı
İnce ayar
Özel uç noktalar
Token başına fiyatlandırma
Prototipten üretime aynı platformda geçiş

En iyisi: Açık modellere standartlaşan ve hız + ince ayarı aynı yerde isteyen ekipler. Benzer açık model kullanımları için Qwen 3.7 API kılavuzuna bakabilirsiniz.

6. Groq: hız kralı

Groq, açık modelleri özel LPU donanımında çalıştırır ve düşük gecikme ile yüksek token/saniye performansı sunar. GroqCloud, OpenAI uyumludur ve Llama, Qwen, Gemma gibi modelleri barındırır.

En iyisi: Sesli ajanlar, gerçek zamanlı uygulamalar ve yanıt hızının model genişliğinden daha önemli olduğu iş yükleri.

7. Fireworks AI: açık modeller için üretim çıkarımı

Fireworks AI, açık modelleri üretim ortamında hızlı ve güvenilir çalıştırmak için kullanılır. OpenAI uyumludur ve şu üretim özelliklerini destekler:

Fonksiyon çağırma
JSON modu
İnce ayar
Ölçekli servis
Açık model çıkarımı

En iyisi: Açık modelleri üretimde çalıştıran, ancak kendi GPU altyapısını yönetmek istemeyen ekipler.

8. LiteLLM: açık kaynaklı, kendi kendine barındırılan ağ geçidi

LiteLLM, 100+ sağlayıcıyı OpenAI formatı arkasında birleştiren açık kaynaklı proxy’dir. Bir SaaS platformuna ödeme yapmak yerine kendi ağ geçidinizi çalıştırırsınız.

LiteLLM ile şunları yapabilirsiniz:

Kendi sağlayıcı anahtarlarınızı yönetmek
Anahtar başına bütçe tanımlamak
Hız limitleri koymak
Harcamaları kaydetmek
İstekleri kendi ağınız içinde tutmak
Platform ücretini sıfırlamak

Karşılığı: altyapı, güvenlik, yükseltme ve bakım sorumluluğu sizdedir.

En iyisi: Tam kontrol, sıfır platform ücreti ve verilerin kendi ortamından çıkmamasını isteyen ekipler.

9. Cloudflare AI Gateway: kenarda önbellekleme ve analitik

Cloudflare AI Gateway, mevcut sağlayıcı API’larınızın önüne oturur. Token yeniden satmaz; sağlayıcı anahtarlarınızı kullanmaya devam edersiniz.

Sağladığı katmanlar:

Önbellekleme
Hız sınırlama
Yeniden deneme
Analitik
Günlükleme
Sağlayıcılar arası gözlemlenebilirlik

En iyisi: Mevcut sağlayıcılarını değiştirmeden önbellekleme, günlükleme ve analitik isteyen Cloudflare kullanıcıları.

10. Eden AI: her yapay zeka modalitesi için tek API

Eden AI, LLM, OCR, konuşma, çeviri ve görsel oluşturma gibi farklı yapay zeka servislerini tek API ve tek fatura altında toplar.

Bu araç, en ucuz sohbet token’ını bulmaktan çok, farklı yapay zeka özelliklerini tek entegrasyonda toplamak isteyen ürün ekipleri için uygundur.

En iyisi: Sohbet dışında OCR, konuşma, çeviri ve görsel işleme gibi özelliklere de ihtiyaç duyan ürünler.

OpenRouter alternatifleri karşılaştırması

Araç	Tür	Model kapsamı	Fiyatlandırma modeli	OpenAI uyumlu	En uygunu
Hypereal AI	Hepsi bir arada ağ geçidi	1.000+ (metin, görsel, video)	Krediler, liste fiyatının altında	Evet	En ucuz kodlama planı + tüm modaliteler
Blackmagic AI	LLM ağ geçidi	13+ sağlayıcı	Ön ödemeli, liste fiyatından %48-74 indirimli	Evet	Derin ön ödemeli LLM indirimleri
Requesty	Akıllı yönlendirici	300+ model	Kullanım + yönlendirme	Evet	Maliyet kontrolleri ile yönlendirme
Portkey	Kurumsal ağ geçidi	200+ model	Kullanım + plan	Evet	Gözlemlenebilirlik ve yönetim
Together AI	Çıkarım bulutu	200+ açık model	Token başına	Evet	Açık modeller + ince ayar
Groq	Çıkarım (LPU)	Seçili açık modeller	Token başına	Evet	En düşük gecikme
Fireworks AI	Çıkarım bulutu	Açık modeller	Token başına	Evet	Üretim açık model hizmeti
LiteLLM	Açık kaynaklı proxy	100+ sağlayıcı	Ücretsiz (kendi kendine barındırma)	Evet	Tam kontrol, sıfır platform ücreti
Cloudflare AI Gateway	Uç ağ geçidi	Sizin sağlayıcılarınız	Ücretsiz + kullanım	Evet (proxy)	Önbellekleme ve analitik
Eden AI	Çok modlu toplayıcı	Birçok sağlayıcı	Kullanım	Evet	Modaliteler genelinde tek API

Apidog ile herhangi bir LLM ağ geçidini test edin ve hata ayıklayın

OpenAI uyumlu iki uç nokta aynı görünebilir; ancak üretimde şu alanlarda farklı davranabilir:

Streaming formatı
Token kullanım bloğu
Hata yanıtı
Rate limit başlıkları
Model adı eşleşmesi
Gecikme
Yanıt şeması

Bu yüzden geçişten önce API seviyesinde doğrulama yapmanız gerekir.

Apidog ile aynı OpenAI uyumlu isteği farklı ağ geçitlerine gönderebilir ve yanıtları karşılaştırabilirsiniz.

Pratik test akışı:

Her sağlayıcı için bir environment oluşturun:
- base_url
- api_key
- model
Aynı /chat/completions isteğini kullanın.
Environment değiştirerek aynı isteği Hypereal, Blackmagic, OpenRouter veya başka bir sağlayıcıya gönderin.
Şunları karşılaştırın:
- İlk token gecikmesi
- Toplam yanıt süresi
- usage.prompt_tokens
- usage.completion_tokens
- Hata formatı
- Streaming çıktısı

Örnek OpenAI uyumlu istek gövdesi:

{
  "model": "{{model}}",
  "messages": [
    {
      "role": "system",
      "content": "Kısa ve teknik yanıt ver."
    },
    {
      "role": "user",
      "content": "Bu API ağ geçidinin streaming davranışını test ediyorum."
    }
  ],
  "temperature": 0.2,
  "stream": true
}

Apidog’da yapmanız gereken doğrulamalar:

stream: true ile SSE çıktısının doğru geldiğini kontrol edin.
usage bloğunun beklediğiniz alanları içerdiğini doğrulayın.
Hata senaryosu için geçersiz model adı deneyin.
Rate limit veya auth hatalarının uygulamanızın beklediği formatta döndüğünü kontrol edin.
Testleri koleksiyon olarak kaydedin ve geçişten sonra tekrar çalıştırın.

Bu listedeki araçların tamamı OpenAI uyumlu olduğu için aynı Apidog koleksiyonunu hepsinde kullanabilirsiniz. Bu yaklaşım, API testi için en iyi Postman alternatifleri kılavuzundaki iş akışına da uyar.

Geçiş sırasında birden fazla API anahtarı yöneteceğiniz için güvenliği de sıkılaştırın. VS Code uzantılarında API anahtarı güvenliği notları burada da geçerlidir.

Apidog’u indirin ve ilk ağ geçitleri arası karşılaştırmanızı birkaç dakika içinde çalıştırın.

OpenRouter’dan üç adımda nasıl geçilir?

OpenAI uyumlu bir hedefe geçiyorsanız süreç mekaniktir.

1. Yeni ağ geçidinde anahtar oluşturun

Önce hedef platformda hesap ve API anahtarı oluşturun.

Hypereal veya Blackmagic kullanıyorsanız kredi yükleyin.
LiteLLM kullanıyorsanız proxy’yi kurun ve sağlayıcı anahtarlarınızı tanımlayın.
Cloudflare AI Gateway kullanıyorsanız mevcut sağlayıcı anahtarlarınızı gateway önüne alın.

2. `base_url`, `api_key` ve model adını değiştirin

OpenAI SDK kullanan örnek yapı:

from openai import OpenAI

client = OpenAI(
    base_url="https://YOUR_GATEWAY_BASE_URL",
    api_key="YOUR_GATEWAY_API_KEY"
)

response = client.chat.completions.create(
    model="YOUR_MODEL_NAME",
    messages=[
        {"role": "user", "content": "Bu yeni ağ geçidini test ediyorum."}
    ]
)

print(response.choices[0].message.content)

Dikkat edin:

Model adları sağlayıcı katalogları arasında farklı olabilir.
claude-opus-4-7 gibi görünen adlar, gateway’e göre farklı slug kullanabilir.
Streaming kullanıyorsanız SDK ve gateway uyumluluğunu ayrıca test edin.

3. Trafiği kademeli taşıyın

Önce Apidog veya curl ile test edin:

curl https://YOUR_GATEWAY_BASE_URL/chat/completions \
  -H "Authorization: Bearer YOUR_GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "YOUR_MODEL_NAME",
    "messages": [
      {
        "role": "user",
        "content": "OpenRouter alternatifini test ediyorum."
      }
    ],
    "temperature": 0.2
  }'

Kontrol edin:

Yanıt formatı doğru mu?
Token sayımı beklediğiniz gibi mi?
Streaming çalışıyor mu?
Hata yanıtları uygulamanız tarafından parse edilebiliyor mu?
Maliyet tahmini doğru mu?

Yeni ağ geçidi birkaç gün kendini kanıtlayana kadar OpenRouter’ı fallback olarak yapılandırılmış tutun.

Sıkça sorulan sorular

Ücretsiz bir OpenRouter alternatifi var mı?

Evet. Hypereal AI’nın dakikada 60 istek sunan ücretsiz katmanı vardır. Cloudflare AI Gateway ücretsiz başlar. LiteLLM açık kaynaklıdır ve kendi kendinize barındırırsanız platform ücreti ödemezsiniz.

Bazı ağ geçitleri ücretsiz veya düşük maliyetli açık modeller de sunar. Ek örnekler için Claude Opus 4.8’i ücretsiz kullanma kılavuzuna bakabilirsiniz.

Hangi OpenRouter alternatifi en ucuz?

İş yüküne bağlıdır.

Claude ve GPT tabanlı kodlama ajanları için Hypereal’in kodlama planı harcamayı 7,7 kata kadar uzatabilir.
Ön ödemeli LLM indirimleri için Blackmagic, liste fiyatından %48-74 indirim sunar.
Açık modeller için Groq ve Together AI düşük token başına fiyatlarla öne çıkar.
LiteLLM’i kendi kendinize barındırırsanız platform ücreti sıfırdır; yalnızca sağlayıcıya ödeme yaparsınız.

Mevcut OpenAI kodum bunlarla çalışır mı?

Genellikle evet. Bu listedeki araçlar OpenAI API formatını destekler. Çoğu geçişte şu alanları değiştirmeniz yeterlidir:

base_url
api_key
model

Yine de streaming davranışı, usage alanı ve hata formatlarını test edin. Uyumluluk farkları en sık bu alanlarda çıkar.

Claude Code ve kodlama ajanları için en iyi OpenRouter alternatifi hangisi?

Hypereal’in kodlama planı bu kullanım senaryosu için güçlü bir seçenektir. Claude Code, Cursor, Cline, Aider, Continue.dev ve OpenCode ile çalışır; Claude ve GPT modellerini resmi API oranlarının altında fiyatlandırır.

Maliyetleriniz yükseliyorsa bunu aracı token maliyetlerini düşürme taktikleriyle birlikte değerlendirin.

OpenRouter hâlâ kullanmaya değer mi?

Evet, özellikle hızlı deneyler ve geniş model kataloğu için hâlâ kullanışlıdır. Ancak %5,5 kredi ücreti, $0,80 minimum ücret ve ayda 1 milyon BYOK isteği sonrası gelen %5 ek ücret, üretim trafiği büyüdüğünde alternatifleri değerlendirmeyi mantıklı hale getirir.

Hypereal görsel ve video modellerini de destekliyor mu?

Evet. Hypereal yalnızca metin modelleriyle sınırlı değildir. Aynı API üzerinden metin, görsel ve video modellerine erişebilirsiniz. Örnek kapsam:

Görsel: Flux 2 Max, Seedream 5.0, Nano Banana 2
Video: Veo 3.1, Sora 2, Kling, WAN

Bu sayede metin ve medya üretimini tek hesap ve tek fatura altında toplayabilirsiniz.

API anahtarlarımı ve verilerimi nasıl güvende tutarım?

Aşağıdaki temel kuralları uygulayın:

API anahtarlarını kaynak koda koymayın.
Ortam değişkenleri veya secret manager kullanın.
Anahtar başına harcama limiti tanımlayın.
Test ve üretim anahtarlarını ayırın.
Ekip erişimini düzenli olarak gözden geçirin.
Gerekiyorsa LiteLLM gibi kendi kendine barındırılan proxy kullanın.

Ek rehberlik için API anahtarı güvenliği yazısına bakabilirsiniz.

Hangi OpenRouter alternatifini seçmelisiniz?

Seçimi iş yüküne göre yapın:

Metin, görsel ve video için tek fatura; ucuz kodlama modelleri; kurumsal kontroller: Hypereal AI ve kodlama planı
OpenRouter benzeri deneyim + daha derin ön ödemeli indirimler: Blackmagic AI
En düşük gecikme veya açık model ölçeği: Groq, Together AI veya Fireworks AI
Tam kontrol ve sıfır platform ücreti: LiteLLM
Mevcut sağlayıcılar üzerinde önbellekleme ve analitik: Cloudflare AI Gateway
LLM dışı modaliteler için tek API: Eden AI

Hangisini seçerseniz seçin, önce ölçün. Apidog içinde OpenAI uyumlu bir istek oluşturun, aynı prompt’u kısa listenizdeki ağ geçitlerine gönderin ve kararı gerçek gecikme, token kullanımı ve hata davranışına göre verin.

İlk yan yana ağ geçidi testinizi çalıştırmak için Apidog’u indirin.