Merchant API nedir, Content API ne zaman kapanıyor?

Merchant API, Merchant Center ürün, stok, fiyat ve hesap işlemlerini yönetmek için kullanılan yeni Google API yapısıdır; Content API erişimi ise 18 Ağustos 2026'da sona eriyor.

Bu tarih, Content API kullanan e-ticaret siteleri için yalnızca bir kütüphane güncellemesi anlamına gelmez. Ürün gönderimi, envanter güncellemesi, kimlik doğrulama, hata yönetimi ve izleme akışlarının birlikte incelenmesi gerekir.

Geçiş yapılmadığında ürün verisi Merchant Center'a ulaşmayabilir. Fiyat ve stok bilgileri güncellenmeyebilir. Bu durum, ücretsiz listelemeleri ve Shopping reklamlarındaki ürün uygunluğunu etkileyebilir.

Merchant API nedir ve Content API'den hangi yönleriyle ayrılır?

Merchant API, Google Merchant Center hesaplarındaki ürün ve ticaret verilerini yönetmek için kullanılan, kaynakları daha ayrıştırılmış yeni API yaklaşımıdır.

Content API for Shopping, uzun süredir ürün ekleme, güncelleme, silme, stok değiştirme ve rapor alma işlemlerinde kullanılan eski entegrasyon katmanıdır. Merchant API ise bu işlemleri farklı kaynaklar ve servisler üzerinden düzenler.

En temel fark, işlemlerin tek bir genel ürün akışı yerine daha belirgin kaynaklara ayrılmasıdır. Ürün verisi, ürün durumu, envanter, promosyon veya hesap bilgileri aynı mantıkla yönetilmez.

Bu ayrım, kod tarafında yalnızca URL değiştirmeyi yetersiz kılar. İstek gövdeleri, kaynak adları, yetkilendirme kapsamları, hata kodları ve yanıt biçimleri yeniden kontrol edilmelidir.

Örneğin bir sistem, Content API üzerinden ürün fiyatını ve stok miktarını tek akışta güncelliyor olabilir. Merchant API geçişinde bu iki işlem farklı operasyonlar gerektirebilir.

Merchant API her işletme için otomatik olarak daha basit değildir. Özellikle özel yazılımlar, çoklu mağaza yapıları ve yüksek ürün sayısına sahip kataloglar için analiz yapılmadan geçişe başlanmamalıdır.

Yanlış: “Eski API adresini yeni adresle değiştirince geçiş tamamlanır.” Doğru: Kullanılan her endpoint, veri alanı, yetki kapsamı ve hata senaryosu ayrı ayrı doğrulanır.

Content API ne zaman kapanıyor ve bu tarih kimi etkiliyor?

Content API erişimi 18 Ağustos 2026'da sona eriyor; bu tarihten sonra eski entegrasyonla Merchant Center'a veri gönderen sistemler çalışmayabilir.

Bu kapanış, Content API kullanan tüm e-ticaret sitelerini aynı şekilde etkilemez. Ürünleri yalnızca Merchant Center arayüzünden yöneten işletmelerin API geçişi yapması gerekmez.

Ancak ürünlerini kendi yazılımından otomatik gönderen mağazalar kapsam içindedir. Stok sistemi, ERP, e-ticaret altyapısı, fiyat motoru veya ajans yazılımı Content API çağrısı yapıyorsa teknik inceleme gerekir.

Bir entegrasyonun etkilenip etkilenmediğini anlamanın en güvenilir yolu kod ve sunucu günlüklerini kontrol etmektir. “Content API”, “shoppingcontent”, “products.insert”, “products.update” veya benzeri çağrı izleri aranmalıdır.

API erişimi doğrudan görünmese bile üçüncü taraf bir uygulama eski servisi kullanıyor olabilir. Bu nedenle yalnızca kurum içi yazılımı değil, Merchant Center'a bağlı uygulamaları da listelemek gerekir.

Kapanış tarihinden önce test yapılmaması, geçiş sorunlarının yoğun satış dönemine kalmasına yol açabilir. Test için yeni API ile sınırlı ürün grubunda veri gönderimi ve sonuç kontrolü yapılmalıdır.

Geçiş gerekmeyen durumlarda bile bağlantılı uygulamalar incelenmelidir. Bir ürün yönetim aracı eski API'ye bağlıysa, Merchant Center hesabındaki ürünlerin güncellenmesi üçüncü taraf yazılım nedeniyle durabilir.

Content API kullanan bir e-ticaret sitesi önce neyi kontrol etmeli?

İlk kontrol, sisteminizin Google Merchant Center'a hangi yöntemle ve hangi sıklıkta veri gönderdiğini belirlemektir.

Ürün akışının kaynağını yazılı olarak çıkarın. ERP, e-ticaret platformu, özel entegrasyon, XML sağlayıcısı veya ajans paneli ayrı satırlarda belirtilmelidir.

Her kaynak için kullanılan API sürümü, çağrılan endpoint, kimlik doğrulama yöntemi, günlük çağrı sayısı ve güncellenen veri alanları kaydedilmelidir.

Ardından tam katalog gönderimi ile kısmi güncellemeleri ayırın. Tam katalog aktarımı ürün başlığı, açıklaması, görseli, bağlantısı ve marka bilgilerini içerebilir.

Kısmi güncellemeler ise fiyat, stok, satış durumu veya teslimat gibi daha sık değişen alanlara odaklanır. Bu iki akışın aynı şekilde taşınacağı varsayılmamalıdır.

Ürün kimliklerinin nasıl oluşturulduğu da önemlidir. Sisteminiz her aktarımda yeni kimlik üretiyorsa, geçiş sonrasında yinelenen ürünler oluşabilir veya mevcut ürün geçmişiyle bağlantı bozulabilir.

Merchant Center hesabı, alt hesaplar ve ülke hedeflemeleri de haritalanmalıdır. Çok satıcılı yapılarda tek bir API hesabı birden fazla alt hesabı yönetiyor olabilir.

Geçiş öncesi şu kontrol listesini kullanabilirsiniz:

• Content API kullanan tüm uygulamaları listeleyin.
• Ürün, envanter, fiyat ve promosyon çağrılarını ayırın.
• API kimlik bilgilerini ve OAuth yetkilerini kaydedin.
• Ürün kimliği oluşturma kuralını doğrulayın.
• Başarılı ve hatalı istek günlüklerini saklayın.
• Test hesabı veya sınırlı ürün grubu belirleyin.
• Geri dönüş planını ve geçiş sorumlusunu yazılı hale getirin.

Merchant API geçişinde hangi teknik adımlar izlenmeli?

Merchant API geçişi, mevcut entegrasyonun envanterini çıkarıp kaynakları yeni API işlemleriyle eşleştirerek yapılmalıdır.

İlk adım, Google'ın güncel Merchant API dokümantasyonunda kullandığınız işlemlerin karşılıklarını bulmaktır. Ürün oluşturma, ürün güncelleme, ürün silme ve stok güncelleme ayrı ayrı incelenmelidir.

İkinci adımda veri eşleştirme tablosu oluşturun. Eski istekteki alan adı, yeni istekteki karşılığı, zorunlu olup olmadığı, veri tipi ve doğrulama kuralı aynı satırda gösterilmelidir.

Üçüncü adım, kimlik doğrulamayı kontrol etmektir. Servis hesabı, OAuth istemcisi, kullanıcı yetkisi ve Merchant Center hesap erişimi yeni entegrasyonun ihtiyaçlarına göre yeniden sınanmalıdır.

Dördüncü adımda hata yönetimi değiştirilmelidir. Eski sistem yalnızca HTTP durum kodunu kaydediyorsa yeni yanıt gövdesindeki hata ayrıntıları ayrıca loglanmalıdır.

Beşinci adım, kota ve istek sıklığı planlamasıdır. Ürün başına gereksiz güncelleme göndermek yerine yalnızca değişen alanları ve değişen ürünleri belirlemek daha kontrollü bir yapı sağlar.

Altıncı adımda idempotency yaklaşımı test edilmelidir. Aynı ürün güncellemesi iki kez gönderildiğinde yeni kayıt oluşmamalı veya veri tutarsızlığı meydana gelmemelidir.

1. Mevcut Content API çağrılarını ve veri alanlarını çıkarın.
2. Her çağrı için Merchant API karşılığını belirleyin.
3. Yetkilendirme ve hesap erişimini test edin.
4. Sınırlı ürün grubuyla test verisi gönderin.
5. Merchant Center'daki ürün durumu ve hata bildirimlerini kontrol edin.
6. Fiyat, stok ve satış durumu değişikliklerini yeniden test edin.
7. Canlı geçişi izleme ve geri dönüş planıyla uygulayın.

Ürün, fiyat ve stok verileri Merchant API ile nasıl yönetilir?

Merchant API geçişinde ürün temel bilgileri, fiyat verisi ve stok bilgisi ayrı güncelleme ihtiyaçları olarak ele alınmalıdır.

Ürün temel bilgileri başlık, açıklama, bağlantı, görsel, marka, GTIN ve ürün kategorisi gibi alanları kapsar. Bu alanlar sık değişmiyorsa tam katalog aktarımıyla daha seyrek güncellenebilir.

Fiyat ve stok bilgileri ise daha hızlı değişebilir. Özellikle kampanya dönemlerinde fiyat ile stok arasındaki gecikme, Merchant Center'da yanlış ürün gösterimine neden olabilir.

Örneğin sitenizde stok tükendiğinde API güncellemesi başarısız olursa ürün reklamda görünmeye devam edebilir. Bu nedenle başarısız isteklerin yalnızca loglanması değil, tekrar denenmesi gerekir.

Tekrar deneme mekanizması sınırsız çalışmamalıdır. Aynı hata sürekli tekrarlanıyorsa sistem, isteği beklemeye almalı ve teknik ekibe bildirim göndermelidir.

Fiyat gönderiminde para birimi, ülke ve hedef pazar bilgileri birlikte kontrol edilmelidir. Sadece sayısal fiyatın doğru olması, ürün teklifinin doğru ülkeye ulaşacağını garanti etmez.

Stok güncellemesinde “mevcut”, “tükendi” veya benzeri durumların sistemler arasında aynı anlama geldiği doğrulanmalıdır. Bir platformdaki boş değer, diğer platformda geçersiz veri sayılabilir.

Merchant Center uyarıları, geçiş testinin önemli bir parçasıdır. Örneğin 500x500 Merchant Center uyarısının nasıl çözüldüğünü bilmek, API geçişindeki teknik başarının ürün uygunluğu anlamına gelmediğini gösterir.

Merchant API ile Content API arasında hangi farklar önemlidir?

İki API arasındaki kritik farklar, kaynak modeli, endpoint yapısı, veri güncelleme biçimi ve hata yönetiminde görülür.

Bu tablo, her Content API işlemine birebir aynı isimde bir Merchant API işlemi bulunacağı anlamına gelmez. Karşılık, işlev ve veri modeli birlikte değerlendirilmelidir.

Örneğin eski sistemde ürün güncellemesi tek fonksiyonla yapılırken yeni yapıda ürün kaynağı ile envanter kaynağı ayrılabilir. Kod, bu iki işlemi farklı zamanlarda yönetebilir.

Geliştirici ekibi ayrıca sürüm kullanımını kontrol etmelidir. Dokümantasyonda örnek olarak gösterilen işlem ile üretimde kullanılan işlem aynı sürümde olmayabilir.

Bir diğer fark, hata sonrası davranıştır. Başarısız ürün güncellemesiyle başarısız stok güncellemesi aynı önem düzeyinde ele alınmamalıdır.

Stok hatası satış uygunluğunu hızlı etkileyebilir. Açıklama veya görsel alanındaki hata ise ürünün incelenmesini gerektirebilir. İzleme sistemi bu öncelik farkını yansıtmalıdır.

Merchant Center geçişinde hangi hatalar ve veri sorunları görülür?

Geçiş sırasında en sık görülen sorunlar yanlış alan eşleştirmesi, yetki eksikliği, ürün kimliği değişimi ve başarısız tekrar denemeleridir.

İlk hata, tüm eski alanların yeni API'de aynı adla ve aynı veri tipiyle bulunacağını varsaymaktır. Metin olarak gönderilen bir değer, yeni yapıda liste veya nesne bekleyebilir.

İkinci hata, yalnızca başarılı HTTP yanıtını kontrol etmektir. Yanıt alınması, ürünün Merchant Center'da onaylandığı anlamına gelmez.

Üçüncü hata, mevcut ürünleri silip yeniden oluşturmaktır. Bu yöntem ürün geçmişini, hata takibini veya raporlama sürekliliğini olumsuz etkileyebilir.

Dördüncü hata, fiyat ve stok güncellemesini tam katalog aktarımına bağlamaktır. Büyük kataloglarda bu yöntem gereksiz çağrı ve gecikme oluşturabilir.

Beşinci hata, görsel ve bağlantı kontrollerini API dışı sanmaktır. API başarılı olsa bile erişilemeyen görsel, hatalı yönlendirme veya geçersiz video bağlantısı ürün sorununa dönüşebilir.

Örneğin Merchant Center'daki video_link hatası, yalnızca API çağrısının başarılı olup olmadığına bakılarak çözülemez. Gönderilen URL'nin erişilebilirliği ve video koşulları da denetlenmelidir.

Benzer şekilde sipariş koşulları ürün uygunluğunu etkileyebilir. Merchant Center minimum sipariş değerinin nasıl eklendiği kontrol edilmeden yalnızca ürün aktarımına odaklanmak eksik test anlamına gelir.

Merchant API geçişi canlıya alınmadan nasıl test edilir?

Canlı geçişten önce Merchant API, sınırlı ürün ve kontrollü hesap koşullarıyla test edilmelidir.

Test grubunu rastgele seçmek yerine farklı ürün tiplerini içerecek şekilde oluşturun. Varyantlı ürün, indirimli ürün, stokta olmayan ürün, farklı marka ve farklı ülke hedeflemesi bulunmalıdır.

İlk testte yalnızca ürün temel bilgilerini gönderin. Ürünlerin beklenen kimliklerle oluştuğunu, başlıkların bozulmadığını ve görsellerin açıldığını kontrol edin.

İkinci testte fiyat değiştirin. Merchant Center'daki değer ile web sitesindeki değer arasında fark oluşup oluşmadığını inceleyin.

Üçüncü testte stok durumunu değiştirin. Ürün stoktan çıktığında satış uygunluğu ve ürün durumu beklenen şekilde güncellenmelidir.

Dördüncü testte hatalı veri gönderin. Eksik zorunlu alan, geçersiz bağlantı veya yanlış veri tipi için sistemin anlamlı hata üretip üretmediğini ölçün.

Beşinci testte aynı isteği tekrarlayın. Tekrarlanan istek yeni ürün oluşturmamalı ve mevcut veriyi beklenmedik şekilde bozmamalıdır.

Test sonuçları ekran görüntüsüyle sınırlı kalmamalıdır. İstek zamanı, ürün kimliği, yanıt kodu, hata mesajı ve Merchant Center'daki sonuç kayıt altına alınmalıdır.

Geçişten sonra en az birkaç gün izleme yapılması gerekir. İzlenecek metrikler; başarılı istek oranı, hata türleri, güncelleme gecikmesi ve ürün durumu değişimleridir.

Content API kapanmadan önce hangi geçiş planı uygulanmalı?

En güvenli plan, keşif, geliştirme, test, paralel izleme ve canlı geçiş aşamalarından oluşur.

Keşif aşamasında tüm API çağrıları ve bağlı uygulamalar çıkarılır. Bu aşama tamamlanmadan geliştirici ekibinden doğrudan kod değişikliği istemek eksik kapsamla çalışmaya neden olur.

Geliştirme aşamasında eski entegrasyonun kopyası üzerinde çalışmak yerine yeni kaynak modeline uygun bir katman oluşturulmalıdır. Böylece ürün ve envanter işlemleri gerektiğinde ayrı yönetilebilir.

Test aşamasında önce düşük riskli ürün grubu seçilmelidir. Yeni kodun tüm kataloğa ilk çalıştırmada uygulanması, hata durumunda etki alanını büyütür.

Paralel izleme aşamasında eski ve yeni sistemin ürettiği sonuçlar karşılaştırılabilir. Ancak iki sistemin aynı ürünü eşzamanlı değiştirmesi veri çakışmasına yol açabileceği için yazma yetkileri dikkatle planlanmalıdır.

Canlı geçiş günü için sorumlu kişiler belirlenmelidir. Teknik ekip, e-ticaret operasyonu ve reklam hesabını yöneten ekip aynı kontrol planını kullanmalıdır.

Geçiş sırasında reklam kampanyalarında değişiklik yapmak yerine önce veri akışının kararlı olduğu doğrulanmalıdır. Google Ads'in işletmeler için çalışma mantığı ayrıca incelenebilir; çünkü ürün verisi ile kampanya ayarları farklı katmanlardır.

Geçiş sonrası izleme süresinde ürün sayısı, reddedilen teklif sayısı, stok güncelleme gecikmesi ve fiyat uyuşmazlığı takip edilmelidir. Bu değerler için mevcut işletme verinizden başlangıç seviyesi oluşturun.

Content API kapanışına kadar beklemek yerine, önce kritik ürün akışını taşımak daha kontrollüdür. Daha sonra promosyon, raporlama veya ikincil hesap işlemleri ayrı sprintlerde tamamlanabilir.

Merchant API geçişi için son kontrol nasıl yapılır?

Son kontrol, yeni API'nin veri gönderdiğini değil, Merchant Center'da doğru ve güncel ticaret verisi oluşturduğunu doğrulamalıdır.

Önce tüm üretim anahtarlarının doğru hesaplara bağlı olduğunu kontrol edin. Test hesabına veri gönderirken üretim hesabını yanlışlıkla güncellememek için hesap kimlikleri açıkça ayrılmalıdır.

Ardından kritik ürünlerden örneklem seçin. Örneklemde farklı fiyat, stok, varyant, görsel, kategori ve teslimat koşulları bulunmalıdır.

Her ürün için web sitesindeki değerleri Merchant Center'daki değerlerle karşılaştırın. Başlık, fiyat, stok, bağlantı ve görsel URL'si en az kontrol edilmesi gereken alanlardır.

Hata günlüklerinde çözümlenmemiş kayıt bırakmayın. Tekrar deneme kuyruğu, başarısız ürün listesi ve bildirim mekanizması canlı sistemde de çalışmalıdır.

İçerik ve politika kontrolleri de tamamlanmalıdır. Merchant Center politikalarının birleşmesiyle ilgili güncel değişiklikleri incelemek, API geçişinden bağımsız ürün uygunluğu sorunlarını ayırmaya yardımcı olur.

Son olarak sorumluluk matrisi hazırlayın. API erişimi, veri doğruluğu, ürün politikaları, reklam kampanyaları ve web sitesi değişiklikleri için ayrı sorumlu belirlenmelidir.

Merchant API'ye geçiş tamamlandıktan sonra eski Content API çağrılarının üretim loglarında görünmediği doğrulanmalıdır. Bu kontrol, sistemde unutulmuş ikinci bir entegrasyon bulunup bulunmadığını gösterir.

18 Ağustos 2026 son tarihinden önce geçişi tamamlamak, yalnızca teknik bir takvim maddesi değildir. Ürün verisinin sürekliliğini korumak için kod, hesap, veri ve izleme katmanları birlikte sınanmalıdır.