Google'ın Shopping için Content API'si tarih oldu: 410 feed hataları ve Merchant API geçiş yolu

Ne oldu

Google, Content API for Shopping (v2.1) hizmetini 18 Ağustos 2026'da kullanımdan kaldırdı ve bunun etkileri şimdi özel feed entegrasyonu çalıştıran herkesi vuruyor. The Trillium Company tarafından dev.to'da yayımlanan bir geçiş kontrol listesine göre, çağrı yapan Google Cloud projesinde etkin bir extension bulunmadığında ürün feed senkronizasyon işleri 1 Eylül 2026'dan bu yana aralıklı olarak HTTP 410 yanıtlarıyla başarısız oluyor. Google'ın kullanımdan kaldırma sayfasına atıf yapan yazı, 2027 başında her isteğin çalışmayı durduracağı uyarısında bulunuyor.

Sorun yalnızca kendi geliştirdikleri entegrasyonları kullananlara özgü: script'ler, cron job'lar veya özel feed servisleri. Ana akım e-ticaret platformlarını veya kurulu uygulamaları kullanan satıcıların genellikle bir şey yapması gerekmiyor, çünkü geçişi sağlayıcı üstleniyor.

Hatayı okumak

Bu başarısızlık kasıtlı; altyapıdaki geçici bir aksaklık değil. 410 yanıtı, content_api_sunset gerekçesi ve shoppingcontent.googleapis.com domain'iyle birlikte ABORTED status'ü taşıyor, ayrıca bir yardım merkezi bağlantısına işaret eden metadata içeriyor. Yazıda öne çıkan iki pratik not var. Birincisi, retry yapmak işe yaramayacak çünkü hatalar kasıtlı ve daha sık hale gelecek. İkincisi, birçok senkronizasyon işi 2xx olmayan yanıtları yuttuğu için çökmek yerine ürünlerin Merchant Center içinde sessizce bayatlamasına izin veriyor. Hata gerekçesinin açıkça loglanması tavsiye ediliyor.

Kod değişikliklerinden önce yapılacak tek seferlik kurulum

Çağrıları yeniden yazmaktan ayrı olarak üç proje düzeyinde adım gerekiyor:

• Google Cloud projesinde Merchant API'yi etkinleştirin.
• Projeyi, birincil (production) Merchant Center hesabına karşı developerRegistration:registerGcp aracılığıyla bir kez kaydedin. Bu adım atlanırsa proje "kayıtlı değil" bildiren bir 401 UNAUTHENTICATED hatası alınır; yazı, kayıttan sonra birkaç dakika beklenmesini tavsiye ediyor.
• Bir API-input data source oluşturun. productInputs.insert bir dataSource query parametresi gerektirir ve halihazırda başka bir data source'un sahip olduğu bir offer eklemek, o offer'ın sahipliğini devralır.

Kimlik doğrulama OAuth 2.0 veya Merchant Center hesabında admin erişimi olan bir service account ile yapılır.

Endpoint'ler nasıl değişiyor

Content API v2.1	Merchant API	Dikkat edilecek nokta
products.insert	productInputs.insert	dataSource zorunlu; attribute'lar productAttributes altına taşıyor
products.delete	productInputs.delete	bu da dataSource gerektiriyor
products.custombatch	karşılığı yok	paralel çağrılar veya HTTP multipart batch kullanın; her batch'te en fazla 2.000 istek
productstatuses.*	products.get / products.list	status artık productStatus içinde yer alıyor
datafeeds.fetchnow	dataSources.fetch

Sessizce başarısız olan payload değişiklikleri

Endpoint yeniden adlandırmalarının ötesinde, birkaç veri formatı değişikliği bariz bir hata vermeden bir senkronizasyonu bozabilir:

• Ürün tanımlayıcıları biçim değiştiriyor: channel:contentLanguage:targetCountry:offerId yerine accounts/{account}/products/{contentLanguagefeedLabelofferId}. channel bölümü kayboluyor, tilde ayırıcı haline geliyor ve /, : ya da ~ gibi karakterler içeren tanımlayıcılar base64url ile kodlanmalı.
• Fiyatlar {"value": "33.45", "currency": "USD"} biçiminden {"amountMicros": "33450000", "currencyCode": "USD"} biçimine geçiyor.
• targetCountry'nin yerini feedLabel alıyor ve availability gibi serbest metin alanları IN_STOCK ve NEW gibi tipli enum'lara dönüşüyor.

Yazının tavsiyesi, her değişikliği yalnızca bir özete güvenmek yerine Google'ın uyumluluk rehberine karşı doğrulamak.

Kod tabanında eski çağrıları bulma

Denetleme sürecine yardımcı olmak için yazının arkasındaki şirket, merchant-migration-scan adında bağımlılığı gerektirmeyen bir tarayıcı geliştiriyor. Depoyu, Python googleapiclient kütüphanesi, PHP Google_Service_ShoppingContent servisi, Node googleapis paketi ve düz REST çağrılarındaki Content API kullanımı açısından statik olarak tarıyor ve her biri için Merchant API karşılığını bir risk notuyla birlikte listeliyor. Ağ çağrısı ve credential gerektirmeyen saf bir metin taraması olduğu için dinamik olarak oluşturulan istekleri kaçırabilir ve bir projenin extension taşıyıp taşımadığını doğrulayamaz; bu yüzden çıktısı, geçişin tamamlandığının kanıtı değil bir kontrol listesi olarak ele alınmalı.

Neden önemli

Sessizce bayatlayan bir feed, bir çökmekten daha kötüdür: ürünler herhangi bir uyarı olmadan Merchant Center'da tazeliğini yitirir ve entegrasyon sağlıklı görünürken listeleri bozar. 410 hatalarının aralıklı doğası bunu özellikle yanıltıcı kılıyor, çünkü bazı istekler hâlâ başarılı olabiliyor ve sorunu 2027 başındaki keskin kesime kadar gizleyebiliyor. Ayrıca geçiş bir base-URL değişikliği değil: kayıt adımı, data source gereksinimi, yeni tanımlayıcı biçimi ve micros tabanlı fiyat biçiminin her biri kod ve test değişiklikleri talep ediyor. Özel feed araçlarına sahip ekipler şimdi 410 gerekçelerini loglamalı, kod tabanlarını eski endpoint'ler açısından taramalı ve geçişi son tarihten çok önce planlamalı.