Online sipariş platformlarının API'leri nasıl çalışır? RestoranTakibi hangi teknolojiyle entegrasyon sağlar ve neden önemlidir?
Bir restoran sahibi için "API entegrasyonu" genelde kapalı bir kutudur: anahtarı girersiniz, siparişler gelmeye başlar. Ama entegrasyon bozulduğunda o kutunun içini bilmek gerekir. Sipariş neden düşmüyor? Panelde "bağlı" yazarken neden sipariş yok? Teslim edilmiş sipariş neden hâlâ hazırlanıyor görünüyor?
Bu yazı, Yemeksepeti, Trendyol Yemek (satıcı tarafında Uber Eats Trendyol Go), Getir Yemek ve Migros Yemek entegrasyonlarının teknik olarak nasıl çalıştığını anlatıyor. Kurulum adımlarını değil, mekanizmayı: siparişin hangi yoldan geldiğini, kimlik bilgisinin kimde durduğunu, mükerrer siparişin nasıl engellendiğini ve bağlantı bozulduğunda sistemin ne yaptığını. Adım adım kurulum arıyorsanız entegrasyon nasıl yapılır rehberi daha uygun; erişimin sağlayıcıdan nasıl alındığı ise platform API süreci sayfasında.
Platformlar sipariş verisini iki yoldan biriyle paylaşır ve bu tercih tamamen platforma aittir; yazılım tarafı buna uyar.
Push (webhook) modelinde platform, yeni siparişi doğrudan yazılımın adresine gönderir. Sipariş, platformda oluştuğu anda sisteme düşer. Bu modelde iş, isteğin gerçekten o platformdan geldiğini doğrulamaktır — imza veya kimlik doğrulaması olmadan açık bir uç, sahte sipariş üretilmesine davetiye çıkarır.
Polling modelinde yazılım belirli aralıklarla platforma "yeni sipariş var mı" diye sorar. RestoranTakibi bu soruyu 15 saniyede bir sorar. Bu modelde iş, hız sınırına takılmadan, aynı siparişi iki kez işlemeden ve bir turu kaçırdığında telafi ederek çalışmaktır.
Sipariş sisteme düştükten sonrası her iki modelde aynıdır: panel, mutfak ekranı ve kurye ekranı açık bir WebSocket bağlantısı üzerinden anında haberdar edilir. Yani gecikme kaynağı entegrasyonun ilk adımındadır, panelin kendisinde değil.
| Platform | Sipariş alma modeli | Restoranın panele girdiği bilgi |
|---|---|---|
| Yemeksepeti | Push (POS Direct webhook) | Yalnız restoran kodu (remoteId) |
| Trendyol Yemek / Trendyol Go | Polling (entegratör API) | API Key, API Secret, Supplier ID |
| Getir Yemek | Polling (partner API) | Getir Restoran Secret Key |
| Migros Yemek | Push (webhook) | Migros API Key + Mağaza No (StoreId) |
Tablodaki fark önemlidir: Yemeksepeti'nde restoran hiçbir teknik anahtar girmez, yalnızca kendi restoran kodunu girer. Getir'de de restoran tek anahtar girer. Bunun sebebi bir sonraki başlıkta.
Bu entegrasyonların çoğunda kimlik iki seviyeden oluşur:
Bu ayrımın pratik sonucu şudur: restoran doğru bilgiyi girse bile entegratör tarafı eksikse bağlantı kurulmaz. Sistem bu durumda "bağlandı" demez. Bağlantı durumu ayrı bir etiket alır ve panelde hangi tarafın eksik olduğu yazılır. Bu, sessizce çalışmayan bir entegrasyondan çok daha iyidir; işletme neyi bekleyeceğini bilir.
Panel dört farklı durumu ayırır ve hepsinin anlamı farklıdır:
"Kaydedildi" ile "bağlı" arasındaki ayrım bilerek konmuştur. Uzaktan doğrulama yapmayan bir entegrasyonda "bağlandı" yazmak yanlış güven verir; işletme siparişin gelmediğini fark ettiğinde iş işten geçmiş olur.
Her sipariş, platformun verdiği kimlikle birlikte kaydedilir. Yeni bir sipariş işlenmeden önce bu kimlikle daha önce kayıt yapılıp yapılmadığı kontrol edilir; varsa atlanır.
Bu, polling modelinde zorunludur. Sorgu her 15 saniyede bir çalıştığı için aynı sipariş art arda birçok turda görünür. Kimlik kontrolü olmasa mutfağa aynı sipariş dakikada dört kez düşerdi.
Push modelinde de aynı koruma gerekir, çünkü platformlar bildirimi teslim edemediğinde tekrar dener. Tekrar denemenin kendisi doğru bir davranıştır; yazılımın görevi, aynı bildirimin ikinci kez sipariş üretmemesini sağlamaktır.
Sipariş kaydedilirken müşteri kaydı da güncellenir: telefon numarasından mevcut müşteri bulunur, adres listesine yeni adres eklenir, sipariş sayısı ve harcama toplamı büyür. Yani platform siparişi de CRM'e işler — nasıl çalıştığı restoran CRM ve müşteri yönetimi yazısında.
Otomatik onay bir tercih ayarı gibi görünür, ama teknik karşılığı siparişin hangi durumda doğduğudur. Ayar açıkken kayıt doğrudan *hazırlanıyor* durumunda açılır, kabul zamanı damgalanır ve platforma "kabul edildi" bildirimi aynı işlemde geri yazılır. Ayar kapalıyken kayıt *yeni* durumunda açılır ve geri yazma, personel onayı verene kadar yapılmaz.
Bu ayrımın bir yan etkisi vardır: sipariş hiç *yeni* durumunda durmaz. Ekranların "yeni sipariş geldi" mantığını yalnız o duruma bağlayan her kurgu, otomatik onay açıldığı anda sessizleşir. Bunu kendi mutfak ekranımızda yaşadık ve düzelttik (mutfak ekranı rehberi). Ayarı hangi işletmenin açıp hangisinin kapatması gerektiğini ise operasyon tarafını anlattığımız platform siparişlerini tek panelde toplama yazısında karşılaştırdık.
Entegrasyon tek yönlü değildir. Panelde siparişi kabul ettiğinizde, hazır işaretlediğinizde ya da iptal ettiğinizde bu bilgi platforma geri yazılır. Her platformun kendi karşılığı vardır: Getir'de doğrulama, hazırlama, kuryeye teslim ve teslim aksiyonları; Migros'ta durum güncelleme servisi; Trendyol'da paket durum uçları.
Kritik nokta, bu bildirimin başarısız olabilmesidir. Ağ koptuysa ya da platform o an cevap vermiyorsa siparişi platformda kabul edilmemiş görünür halde bırakmak ciddi bir kayıptır. Bu yüzden bildirim tek denemede bırakılmaz: 5 saniye, 30 saniye ve 120 saniye sonra tekrar denenir. Dördüncü deneme de başarısız olursa sessizce vazgeçilmez; denetim kaydı yazılır ve yöneticilere "platform durum bildirimi başarısız, platform panelinden elle onaylayın" uyarısı gider.
İptal en çok kural içeren adımdır ve yazılım bu kuralları uydurmaz, platformun kuralına uyar. Örneğin Migros'ta henüz onaylanmamış bir siparişi reddetmek ile onaylanmış bir siparişi iptal etmek iki ayrı servistir; hazırlanmış sipariş ise API üzerinden hiç iptal edilemez, işletmenin platformla görüşmesi gerekir. Ayrıca sipariş oluştuktan sonra kısa bir bekleme süresi vardır. Bunlar bilinmezse "iptal ettim ama platformda duruyor" durumu ortaya çıkar.
Entegrasyonların en sinsi hatası şudur: sipariş gelir, mutfakta yapılır, kurye teslim eder, ama panelde sonsuza kadar "hazırlanıyor" kalır. Sebep genelde tek yönlü akıştır — bizim gönderdiğimiz durum gider, platformda değişen durum geri gelmez.
Buna karşı iki katman vardır:
Eski davranış şuydu: kimlik hatası alınır, kısa süre beklenir, tekrar denenir. Bu bir döngüdür ve anahtar düzeltilmezse sonsuza kadar sürer; log dosyası dolar, platformun kotası boşa harcanır, bağlantı "bağlı ama çalışmıyor" halinde kalır.
Bugünkü davranış farklıdır: art arda iki kimlik hatasında o platform için otomatik sipariş çekme durdurulur ve bu durum veritabanına yazılır — sunucu yeniden başlasa bile denenmez. Bunun yerine 6 saatte bir tek bir doğrulama isteği atılır. Anahtar düzeltilmişse bağlantı kendiliğinden açılır.
Aynı anda işletmeye e-posta gider: hangi platformun bağlantısının çalışmadığı ve siparişlerin panele düşmediği açıkça yazılır. Bu e-posta 24 saatte bir defadan fazla gönderilmez, ama panelden yeni anahtar girildiğinde bu sayaç sıfırlanır — yeni bilgiler de hatalıysa işletme tekrar haberdar olur.
Sipariş akışı ile menü senkronu ayrı konulardır ve platformdan platforma değişir. Migros tarafında panelden ürün ve seçenek bazında satışa açma/kapatma ile toplu fiyat güncelleme çalışır. Burada sıralama bilinçlidir: önce platforma yazılır, platform kabul ederse yerel kayıt güncellenir. Ters sırada yapılsaydı panelde "kapalı" yazarken platformda satış sürerdi.
Fiyat tarafında teknik olarak bilinmesi gereken tek kural şudur: platform siparişinin kalem fiyatı platformun gönderdiği veriden okunur, panelin kendi kanal fiyatı tablosundan değil. Sebep basit — müşteri o tutarı platformda görüp ödemiştir, yerelde farklı bir fiyat yazmak muhasebeyi platformla uyumsuz hale getirir. Kanal fiyatının hangi kanallarda geçerli olduğunu ve paket kârlılığında ne işe yaradığını platform siparişlerini tek panelde toplama yazısında ayrıntılandırdık.
Bu yazıdaki mekanizmaların tamamı dört platform için de yazılmış durumda. Ama bir entegrasyonun kodunun hazır olması, sizin işletmenizde sipariş akacağı anlamına gelmez: arada platformun entegratör onayı ve işletmenin platformdan aldığı erişim vardır. Eylül 2026 itibarıyla Trendyol Yemek ve Migros Yemek tarafında akış canlıdır; Yemeksepeti ve Getir tarafında altyapı hazır, bağlantı erişime bağlıdır. Kanal bazında güncel olgunluk entegrasyonlar sayfasında tutulur, erişimin nasıl alındığı platform API süreci sayfasında anlatılır.
Bir de yön değişikliği var: Getir Yemek satıcı işlemleri Uber Eats Trendyol Go tarafına taşınıyor, yani yeni kurulacak bağlantı için Trendyol Go daha uzun ömürlü seçenek. Komisyonun gerçek maliyeti sipariş platformu komisyonları yazısında hesaplanıyor.
Bağlantı başına ek entegrasyon ücreti alınmaz; ücretlendirme tek modeldir ve fiyatlar sayfasında yazar.
Push modelinde sipariş platformda oluştuğu anda size gönderilir; polling modelinde yazılım 15 saniyede bir sorar. Restoran açısından fark bir sipariş için en fazla birkaç saniyedir; asıl fark hata durumlarında ortaya çıkar, çünkü iki model farklı şekilde bozulur ve farklı şekilde toparlanır.
Yemeksepeti entegrasyonu Delivery Hero POS Direct modeliyle çalışır ve teknik kimlik bilgileri restoran başına değil, entegratör düzeyinde tanımlanır. Restoranın panele girdiği tek şey Yemeksepeti'nin kendisine verdiği restoran kodudur (remoteId).
Önce durum etiketine bakın: 'kaydedildi' bilgilerin girildiğini ama henüz doğrulanmadığını, 'yapılandırma eksik' entegratör tarafının tamamlanmadığını, 'bilgiler geçersiz' anahtarın hatalı olduğunu söyler. Gerçekten 'bağlı' yazıyorsa ve sipariş yoksa, platform tarafında mağazanız kapalı veya menü yayında olmayabilir.
Hayır. Her sipariş platformun verdiği kimlikle kaydedilir ve yeni bir kayıt açılmadan önce bu kimliğin daha önce işlenip işlenmediği kontrol edilir. Bu koruma hem polling turlarının tekrarına hem de platformun webhook yeniden denemelerine karşı gereklidir.
Bildirim platforma gönderilir, ancak platformun kendi kuralları geçerlidir. Örneğin Migros'ta onaylanmamış siparişi reddetmek ile onaylanmış siparişi iptal etmek ayrı servislerdir ve hazırlanmış sipariş API üzerinden hiç iptal edilemez. Bildirim üç kez yeniden denenir, yine de başarısız olursa yöneticiye uyarı düşer ve platform panelinden elle onaylamanız istenir.
Bu, durum bilgisinin yalnız tek yönde aktığı entegrasyonlarda görülür. Buna karşı iki katman çalışır: destekleyen platformlarda uzak durumlar periyodik olarak okunup yerele yansıtılır, 36 saatten uzun süredir açık kalan siparişler ise ayrıca sorgulanıp kapatılır. Geç kapatmada stok düşümü yapılmaz, çünkü eski bir satışın malzemesini bugünün stoğundan düşmek sayımı bozar.
Evet. Art arda iki kimlik hatasında o platform için otomatik sipariş çekme durdurulur ve işletme e-postasına hangi platformun çalışmadığı yazılır. Sonrasında 6 saatte bir tek doğrulama isteği atılır; anahtarı düzelttiğinizde bağlantı kendiliğinden açılır.
Hayır. Platform siparişinin kalem fiyatı, panelin kanal fiyatı tablosundan değil platformun gönderdiği veriden okunur; aksi halde yerel kayıt ile platformun tahsil ettiği tutar birbirini tutmazdı. Kanal fiyatı yalnız kendi kanallarınızda (masa, QR, telefon, kasa) devrededir.
Hayır, kanal bağlantıları için ek entegrasyon ücreti alınmaz. Tek fiyat vardır ve fiyatlar sayfasında yazılıdır. Platformların kendi komisyonları ise bizden bağımsızdır, sözleşmenizde tanımlıdır.
Yeni bir bağlantı kuracaksanız Trendyol Go üzerinden ilerlemek daha uzun ömürlü bir seçim: Getir Yemek tarafındaki satıcı işlemleri Uber Eats Trendyol Go'ya devrediliyor. Mevcut Getir bağlantınız devir tamamlanana kadar çalışmaya devam eder.