Merchant API'ye geçiş nasıl yapılır?

Merchant API'ye geçiş, mevcut Content API entegrasyonunu inceleyip veri kaynaklarını eşleyerek, yeni kimlik doğrulama ve uç noktaları test edip üretime almaktır. Google, Merchant API'yi Content API'nin yerine birincil programatik arayüz olarak konumlandırdı. Content API'nin 18 Ağustos 2026'da kapanacağı açıklandığı için geçişi bu tarihe bırakmamak gerekir.

Geçiş yalnızca endpoint adreslerini değiştirme işlemi değildir. Ürünler, stok, fiyat, sipariş, kampanya, raporlama ve hesap işlemleri farklı kaynak yapılarıyla ele alınabilir. Bu nedenle önce mevcut entegrasyonun hangi fonksiyonları kullandığı çıkarılmalıdır.

Merchant API'ye geçiş neden gerekiyor?

Merchant API'ye geçiş gerekiyor çünkü Content API'nin 18 Ağustos 2026'da kapanacağı açıklandı. Kapanıştan sonra yalnızca Content API kullanan bağlantılar ürün veya hesap işlemlerini sürdüremeyebilir.

Geçiş kararını yalnızca tarih nedeniyle vermek yeterli değildir. Önce entegrasyonun hangi işlemleri otomatik yaptığını belirlemek gerekir. Bir mağaza sadece ürün gönderiyorsa plan farklı, sipariş ve raporları da çekiyorsa plan daha kapsamlıdır.

Örneğin günlük ürün senkronizasyonu yapan yazılımda şu işlemler bulunabilir: ürün oluşturma, ürün güncelleme, stok güncelleme, fiyat güncelleme, ürün silme ve hata raporu alma. Her işlem Merchant API karşılığında ayrı incelenmelidir.

Content API ile Merchant API arasında birebir isim eşleşmesi bulunacağını varsaymak risklidir. Kaynak adları, istek gövdeleri, yetkilendirme yöntemi, sürüm kullanımı ve hata davranışı değişebilir.

Yanlış: Content API URL'sindeki bölümü Merchant API ile değiştirip entegrasyonu canlıya almak.

Doğru: Kullanılan işlemleri listelemek, her birini Merchant API dokümantasyonundaki karşılığıyla eşlemek, test hesabında doğrulamak ve sonra kademeli geçiş yapmaktır.

Geçişin işe yaramadığı durum genellikle API'den değil, kapsam analizinin yapılmamasından kaynaklanır. Sadece ürün ekleme testi başarılı olduğu halde sipariş veya rapor modülleri çalışmayabilir.

Geçişten önce mevcut Content API kullanımı nasıl çıkarılır?

Mevcut Content API kullanımını çıkarmak için kod, zamanlanmış görevler, hata kayıtları ve kullanılan hesapları birlikte incelemek gerekir. Sonuç, işlem bazlı bir envanter tablosu olmalıdır.

İlk adımda uygulamadaki API çağrılarını arayın. Endpoint metinleri, istemci kütüphaneleri, OAuth kapsamları, servis hesabı tanımları ve görev adları bu taramada bulunmalıdır.

1. Üretim ve test ortamlarındaki API çağrılarını listeleyin.
2. Her çağrının hangi mağaza hesabına ve ülkeye ait olduğunu yazın.
3. Gönderilen alanları, yanıt alanlarını ve hata kodlarını kaydedin.
4. Çağrı sıklığını ve çağrıyı başlatan sistemi belirleyin.
5. Merchant API karşılığını ve test yöntemini her satıra ekleyin.

İnceleme sırasında yalnızca uygulama koduna bakmayın. E-ticaret platformunun eklentileri, sunucu cron görevleri, veri ambarı işleri ve ajans tarafından kurulmuş otomasyonlar da çağrı yapabilir.

Çağrı sıklığı ayrıca önemlidir. Stok değişiklikleri dakikalar içinde gönderilirken kategori veya açıklama güncellemeleri günde bir kez çalışabilir. Yeni API planı bu farklı ihtiyaçları ayrı ele almalıdır.

Aşağıdaki kontrol listesi geçiş öncesi eksik alanları görünür kılar:

• Ürün ekleme ve güncelleme çağrıları listelendi.
• Stok, fiyat ve satış durumu senkronizasyonu ayrıştırıldı.
• Promosyon, yerel envanter veya sipariş işlemleri kontrol edildi.
• OAuth istemcileri, kapsamlar ve servis hesapları kaydedildi.
• Hata loglarının tutulduğu sistem belirlendi.
• Test ve üretim hesapları birbirinden ayrıldı.

Bu envanter hazırlanmadığında geçiş kapsamı eksik görünür. Özellikle yalnızca ürün feed'ini kontrol eden ekipler, sipariş veya raporlama bağlantılarını gözden kaçırabilir.

Merchant API için kimlik doğrulama nasıl hazırlanır?

Merchant API kimlik doğrulaması, kullanılan uygulamanın erişim modeline göre OAuth 2.0 yetkilendirmesi ve uygun hesap izinleriyle hazırlanır. Mevcut Content API yetkilendirmesi otomatik olarak yeterli kabul edilmemelidir.

Önce uygulamanın hangi hesap adına işlem yaptığını belirleyin. Tek bir Merchant Center hesabı kullanan mağaza ile çok sayıda müşteri hesabını yöneten yazılımın yetki yapısı aynı değildir.

OAuth istemci bilgileri, erişim token'ları, yenileme token'ları ve güvenli saklama yöntemi ayrı ayrı kontrol edilmelidir. Token değerlerini kaynak koduna, tarayıcıya veya herkese açık loglara yazmayın.

Hesap yetkisi de uygulama yetkisinden farklıdır. API bağlantısı teknik olarak kurulsa bile kullanıcı veya servis hesabı ilgili Merchant Center hesabında gerekli role sahip değilse istekler reddedilebilir.

Yeni bağlantıda şu testleri ayrı yapın: başarılı kimlik doğrulama, yetkisiz hesap erişimi, süresi dolmuş token, eksik kapsam ve yanlış hesap kimliği. Her senaryonun beklenen hata sonucu kaydedilmelidir.

İstek başına hata almakla bütün entegrasyonun durması aynı problem değildir. Uygulama geçici hatalarda yeniden deneme, kalıcı doğrulama hatalarında ise manuel inceleme akışı kullanmalıdır.

Yeniden deneme mekanizması sınırsız çalışmamalıdır. Aynı ürünü kısa aralıklarla tekrar göndermek kota, gecikme veya yinelenen işlem sorunları oluşturabilir. Deneme sayısı ve bekleme aralığı loglanmalıdır.

Geçiş sırasında eski ve yeni kimlik bilgilerini aynı anda üretimde kullanmak yerine ortamları ayırın. Testte Merchant API, üretimde Content API çalışıyorsa geçiş farkları kontrollü şekilde karşılaştırılabilir.

Kimlik doğrulama testinin işe yaramadığı durum, yalnızca token almayı başarı saymaktır. Token alınabilir; ancak hesap erişimi, kaynak yetkisi veya belirli işlem kapsamı yine de başarısız olabilir.

Content API verileri Merchant API'ye nasıl eşlenir?

Content API verilerini Merchant API'ye eşlemek için her eski çağrıyı kaynak, işlem, alan, yanıt ve hata davranışı açısından ayrı bir eşleme satırına dönüştürün.

Ürün verisinde önce zorunlu ve isteğe bağlı alanları ayırın. Kimlik, başlık, açıklama, bağlantı, görsel, fiyat, stok, marka, GTIN ve durum bilgileri aynı öncelikte değerlendirilmemelidir.

Alan adının değişmemesi, anlamının değişmediği anlamına gelmez. Bir alanın veri tipi, kabul ettiği değerler, ülke bağlamı veya güncelleme yöntemi farklı olabilir.

Örneğin fiyatı metin olarak saklayan eski bir sistem, yeni istekte para birimiyle birlikte beklenen biçime ihtiyaç duyabilir. Bu dönüşüm API çağrısından önce yapılmalıdır.

Güncelleme stratejisi de eşlenmelidir. Ürün değişikliğinde tüm ürün gövdesi mi gönderilecek, yoksa belirli alanlar mı güncellenecek? Bu karar veri kaynağının yapısına göre verilmelidir.

Yanlış eşleme, API'nin isteği kabul etmesinden sonra da sorun çıkarabilir. İstek teknik olarak başarılı olur; ancak ürün yanlış ülkeye, yanlış fiyatla veya eksik stok bilgisiyle yayınlanabilir.

İçerik ve yapılandırılmış veri tarafındaki değişiklikleri de izleyin. Ürün sayfanızdaki merchant listing işaretlemesini kontrol etmek için ürün sayfasında Merchant listing şeması nasıl kurulur rehberindeki adımlar kullanılabilir.

Ürün, stok ve fiyat aktarımı nasıl test edilir?

Ürün, stok ve fiyat aktarımı; küçük, temsil gücü yüksek bir ürün grubuyla başlayıp doğrulama sonuçları karşılaştırılarak test edilmelidir. İlk testte bütün kataloğu göndermek kontrollü değildir.

Test grubuna farklı ürün tipleri koyun. Stokta olan, stokta olmayan, indirimli, varyantlı, görselli, GTIN bilgisi bulunan ve eksik alan içeren ürünler birlikte seçilmelidir.

Her ürün için eski sistemdeki değerleri ayrı kaydedin. Yeni API yanıtını yalnızca HTTP başarısıyla değil, Merchant Center'daki ürün durumu ve görünen değerlerle karşılaştırın.

Testte şu sonuçları ölçün: kabul edilen ürün sayısı, reddedilen ürün sayısı, uyarı alan ürün sayısı, stok farkı, fiyat farkı ve işlenme gecikmesi.

Bir ürünün kabul edilmesi, arama sonuçlarında hemen gösterileceği anlamına gelmez. Ürün verisinin politika, hedef ülke, web sitesi ve hesap gereklilikleriyle birlikte değerlendirilmesi gerekir.

Stok testinde en az üç durum oluşturun: stokta, stokta değil ve sınır stok. Sınır stok değeri mağazanın operasyon kuralına göre belirlenmelidir; evrensel bir sayı yoktur.

Fiyat testinde normal fiyat, indirimli fiyat ve indirim bitiş zamanı birlikte incelenmelidir. Web sitesindeki fiyat ile gönderilen fiyat arasında fark oluşuyorsa kaynak sistemlerin zamanlaması kontrol edilmelidir.

Varyantlı ürünlerde ebeveyn ve alt ürün kimliklerini ayrıca doğrulayın. Renk, beden veya diğer varyant özellikleri karışırsa tek ürün yerine hatalı birleşmiş ya da eksik ürünler görülebilir.

Geçişin işe yaramadığı durum, sadece API yanıt kodlarını raporlamaktır. Gerçek kontrol, gönderilen veri ile Merchant Center'da işlenen verinin aynı ürün bazında karşılaştırılmasıdır.

Özel ürün alanları ve politika bilgileri nasıl taşınır?

Özel ürün alanlarını taşımak için her alanın Merchant API'deki karşılığını, kabul edilen değerlerini ve ilgili hesap politikasını ayrı doğrulamak gerekir. Alanı göndermek tek başına yeterli değildir.

İade politikası, enerji verimliliği ve yetişkin içerik değerlendirmesi gibi konuların ürün verisiyle karıştırılmaması gerekir. Bazıları ürün özelliği, bazıları hesap veya politika yapılandırması olarak ele alınabilir.

İade bilgilerini taşıyorsanız önce mevcut Merchant Center politikasını belgeleyin. Ülke, iade süresi, iade yöntemi ve ücret bilgileri değiştiyse ürün gönderiminden bağımsız kontrol yapılmalıdır.

Merchant Center iade politikası nasıl taşınır rehberinde, bu bilgilerin geçiş öncesinde hangi başlıklarla incelenebileceği açıklanıyor.

Enerji verimliliği alanları belirli ürün ve pazarlar için önem taşıyabilir. Bu alanları tüm ürünlere rastgele eklemek yerine hangi kategorilerde gerektiğini veri kaynağıyla belirleyin.

Enerji verimliliği değerlerinin güncellenmesi gerekiyorsa Merchant Center enerji verimliliği alanının nasıl güncelleneceği konusundaki alan ve doğrulama adımlarını takip edin.

Yetişkin içerik değerlendirmesiyle ilgili alanlarda da değerlerin ürün bazında doğru üretilmesi gerekir. Bu alanı mağazanın bütün kataloğuna varsayılan olarak eklemek yanlış sonuç doğurabilir.

Merchant Center'da hasAdultConsideration nasıl eklenir rehberini, ilgili ürünlerin ayrıştırılması ve alanın doğru koşulda gönderilmesi için kullanabilirsiniz.

Özel alan testinde karşı durum mutlaka bulunmalıdır. Alanın gerekli olmadığı üründe alan gönderildiğinde ne olduğu, eksik bırakıldığında ne olduğu ve geçersiz değer verildiğinde hangi hata döndüğü kaydedilmelidir.

Merchant API geçişi nasıl kademeli yayınlanır?

Merchant API geçişi, önce test ortamında, ardından sınırlı ürün grubunda ve son olarak tüm katalogda kademeli yayınlanmalıdır. Tek seferde bütün trafiği değiştirmek geri dönüş riskini artırır.

İlk canlı grubu ürün sayısına göre değil, veri çeşitliliğine göre seçin. Farklı kategori, fiyat, varyant ve stok durumlarını içeren küçük bir grup daha yararlı sonuç verir.

Eski ve yeni sistem aynı ürünleri gönderiyorsa çakışma ihtimali oluşabilir. Bu nedenle iki sistemin aynı kaynağı hangi zamanlarda güncellediği ve son yazanın kim olduğu açıkça belirlenmelidir.

Kademeli yayın planında bir geri dönüş koşulu yazılı olmalıdır. Örneğin kritik hata oranı yükselirse, ürün reddi belirli bir eşiği aşarsa veya stok farkı görülürse yeni akış durdurulmalıdır.

Burada rastgele eşik belirlemeyin. Mağazanın normal hata oranını geçişten önce ölçün ve yeni sistemle bu başlangıç değerini karşılaştırın.

İzlenecek temel göstergeler şunlardır: başarılı istek oranı, reddedilen ürün oranı, uyarı oranı, stok eşleşmesi, fiyat eşleşmesi, veri işleme süresi ve tekrar deneme sayısı.

Canlıya geçiş sırasında değişiklik günlüğü tutun. Hangi tarihte hangi ürün grubunun, hangi hesapta ve hangi sürümle Merchant API üzerinden gönderildiği kayıt altına alınmalıdır.

Geçiş sırasında kampanya veya yoğun satış dönemi varsa planı buna göre ayarlayın. Kritik satış günlerinde veri akışını değiştirmek, teknik hata ile ticari dalgalanmayı ayırt etmeyi zorlaştırır.

Kademeli yöntemin işe yaramadığı durum, grupları yalnızca zaman aralığıyla büyütmektir. Her aşamada ölçüm yapılmadan katalog kapsamını artırmak, hatanın hangi aşamada başladığını belirsizleştirir.

Merchant API geçişinden sonra ölçüm nasıl kontrol edilir?

Geçişten sonra ölçüm, API başarı durumundan ayrı olarak Merchant Center, web sitesi analitiği ve reklam raporları arasında karşılaştırılmalıdır. Teknik başarı, ticari verinin doğru ölçüldüğünü kanıtlamaz.

Önce ürün tıklamalarının ve dönüşümlerinin doğru URL'lere gittiğini kontrol edin. Ürün bağlantıları, varyant parametreleri veya izleme etiketleri değiştiyse analitik verisi farklı görünebilir.

URL parametreleri eksikse kampanya, ürün veya kaynak ayrımı bozulabilir. Böyle bir sorun görürseniz GA4'te eksik URL parametresini düzeltme adımlarını kontrol edin.

Karşılaştırmada aynı tarih aralığını kullanın. Merchant Center'daki ürün sayısı ile GA4 oturumlarını doğrudan eşit beklemeyin; sistemlerin sayım zamanı ve kapsamı farklı olabilir.

Önemli olan değişimin yönünü ve nedenini açıklayabilmektir. Ürün sayısı artarken tıklama düşüyorsa bağlantı, uygunluk, ürün durumu veya izleme değişiklikleri sırayla incelenmelidir.

Reklam trafiğinde kanal bazlı kaliteyi ayrıca izleyin. Özellikle video veya Shorts kaynaklı trafikte geçersiz trafik ihtimali varsa Google Ads Shorts geçersiz trafiğinin nasıl ölçüleceği konusundaki ayrımı kullanın.

Search Console verilerini de tek başına Merchant API geçişinin sonucu olarak yorumlamayın. AI Overview gibi yeni arama görünümlerindeki tıklama sayımını incelemek için AI Overview tıklamasının Search Console'da nasıl sayıldığına bakabilirsiniz.

İzleme kontrolünün işe yaramadığı durum, geçiş günündeki tek günlük veriyi karar ölçütü yapmaktır. Önceki dönemle aynı koşulları karşılaştırın ve olağan sezon etkilerini ayrıca not edin.

Content API kapanmadan önce geçiş planı nasıl tamamlanır?

Content API kapanmadan önce geçiş planı; kapsam, sorumlu kişi, test sonucu, canlıya geçiş tarihi, geri dönüş koşulu ve son doğrulama adımlarını içermelidir.

İlk olarak kullanılan tüm modüllerin Merchant API karşılığını bulun. Karşılığı henüz uygulanmamış bir sipariş, rapor veya kampanya modülü varsa bunu “tamamlandı” olarak işaretlemeyin.

İkinci olarak test kanıtlarını arşivleyin. Başarılı ve başarısız ürün örnekleri, API yanıtları, Merchant Center durumları ve ölçüm karşılaştırmaları aynı geçiş kaydında bulunmalıdır.

Üçüncü olarak üretim geçişini düşük riskli bir zaman aralığına planlayın. Veri akışının durması halinde elle uygulanacak geçici işlem varsa sorumlusu ve süresi yazılı olmalıdır.

Dördüncü olarak eski bağlantının kapatılmasını hemen yapmayın. Merchant API akışı doğrulandıktan, izleme sonuçları incelendikten ve geri dönüş ihtiyacı kalmadıktan sonra eski görevleri devreden çıkarın.

Eski istemci bilgilerini korumak güvenlik açısından doğru değildir. Kullanılmayan anahtarları, token'ları, servis hesaplarını ve zamanlanmış görevleri geçiş sonrası gözden geçirin.

Son kontrolde ürün sayısından çok veri tutarlılığına bakın. Kimlik, fiyat, stok, hedef ülke, bağlantı ve politika bilgileri ürün örnekleriyle karşılaştırılmalıdır.

Planın işe yaramadığı durum, yalnızca bir geçiş tarihi yazıp sahiplik tanımlamamaktır. Her kontrolün yanında sorumlu kişi, beklenen çıktı ve başarısızlık halinde uygulanacak işlem bulunmalıdır.