Platform mimarisi

Bu sayfa, platformu kullanırken karşılaşacağınız yapıyı anlatır: OTO hangi parçalardan oluşur, veri platforma nereden girip nereden çıkar ve neler birbirinden ayrı tutulur. Bir iç mühendislik şeması değildir; OTO’yu değerlendiren veya OTO ile entegrasyon geliştiren kişiler için yazılmıştır.

Dört arayüz, tek platform

Tüm arayüzler aynı veriyle çalışır. Değişen tek şey, veriye kimin ve hangi cihazdan baktığıdır.

Arayüz	Kim kullanır?	Ne için?
Gösterge Paneli	Operasyon, müşteri hizmetleri, finans ve yöneticiler	Siparişler, gönderiler, stoklar, kurallar ve ayarlar; yani platformun tamamı.
OTO PACK	El terminali kullanan depo ve mağaza çalışanları	Raf ve barkodlarla toplama, paketleme, sevkiyat ve gelen ürün kabulü. Bkz. Depo Yönetimi.
OTO FLEX	Telefonla çalışan kendi sürücüleriniz	Rotalar, teslim almalar, teslimatlar ve teslimat kanıtı. Bkz. OTO FLEX.
Müşteri sayfaları	Müşterileriniz	Kendi alan adınızda ve markanızla takip, iade ve adres doğrulama sayfaları. Bkz. Markalı sayfalar.

Dördünün altında da aynı REST API çalışır. Gösterge Panelinin ayrıcalıklı bir erişimi yoktur; panelde yapılabilen her şeyi kendi sistemleriniz de yapabilir.

Veri platforma nasıl girer ve çıkar?

Yön	Kanal
Giriş	Satış kanalları: bağlı e-ticaret siteleri ve pazaryerlerinden anında senkronize edilen siparişler.
	API: kendi sistemlerinizin gönderdiği siparişler, ürünler ve stok bilgileri.
	Gösterge Paneli: elle sipariş girişi ve toplu yükleme.
	Barkod okutma: gelen ürün kabulü, toplama, paketleme ve teslimat sırasında okutulan barkodlar.
Çıkış	Kargo şirketleri: gönderi kayıtları gider, takip bilgileri geri gelir.
	Mesajlaşma sağlayıcıları: kendi hesaplarınız üzerinden SMS, e-posta ve WhatsApp. Bkz. Mesajlaşma sağlayıcıları.
	Satış kanalları: stok seviyeleri, sipariş durumları ve takip linkleri kanala geri yazılır.
	Webhook’lar: olaylar gerçekleştiği anda sistemlerinize gönderilir. Bkz. Webhook.

Her şey siparişin etrafında döner

Mimari açıdan platformu tutarlı kılan şey, siparişin ödeme anından teslimata kadar tek bir kayıt olmasıdır. Gönderiler, paketler, toplama işlemleri, mesajlar, iadeler ve ücretler ayrı sistemlerde tutulmaz; hepsi bu kayda bağlanır.

Her sorunun tek bir cevabı olmasının nedeni buYönlendirme kuralları mesafeyi ve stoğu birlikte değerlendirebilir, çünkü ikisini de aynı kayıtta görür. Takip sayfası dört farklı kargo şirketinin durumunu tek bir standart durumla gösterir, çünkü tüm durumlar aynı siparişe yazılır. Bir iade orijinal satışla eşleşir, çünkü baştan beri aynı siparişin parçasıdır.Ortak bir kayıt olduğunda bunların hepsi kolaydır; olmadığında gerçekten zordur. Birbirine bağlanmış araçlar yerine tek bir operasyon platformu kullanmanın mimari gerekçesi de budur.

Neler birbirinden ayrı tutulur?

Tek bir hesabın içinde çok şey bulunabilir. Önemli olan sınırlar şunlardır:

Sınır	Neyi ayırır?
Hesap	İşletmenizi. En dış sınırdır; hiçbir veri bu sınırı geçmez.
Marka	Tek hesap içindeki ticari kimlikleri: logo, gönderici adı, mesaj şablonları ve takip sayfası. Bkz. Temel kavramlar.
Hub	Her lokasyonun stoğunu, çalışanlarını, raflarını, toplama yöntemini ve çalışma saatlerini. Bkz. Hub Yönetimi.
Kullanıcı kapsamı	Bir kişinin hangi hub’larda çalışabileceğini, hangi ekranları görüp hangi işlemleri yapabileceğini. Bkz. Kullanıcılar, roller ve yetkiler.
Alt hesap	Pazaryeri işletenler için: her satıcı, bir ana hesaba bağlı ayrı bir hesaptır. Bkz. Pazaryerleri.

Platform nerede çalışır?


Barındırma	Yönetilen bir genel bulut altyapısı. Kurmanız veya güncellemeniz gereken hiçbir şey yoktur.
Verinin konumu	Kurulum sırasında belirlenir. Verilerinin Suudi Arabistan’da kalması gereken işletmeler için ülke içi barındırma seçeneği vardır. Bkz. Güvenlik ve uyumluluk.
Ağ güvenliği	Platformun önünde bir web uygulaması güvenlik duvarı (WAF) bulunur.
Sertifikalar	ISO 27001 ve SOC 2 Type II; ikisi de 2026 yılına ait.

Ortamlar

Ortam	Temel URL	Açıklama
Canlı ortam	`https://api.tryoto.com`	Gerçek siparişler, gerçek kargo şirketleri, gerçek faturalar.
Test ortamı (Sandbox)	`https://staging-api.tryoto.com`	Aynı endpoint’ler ve veri yapıları, test kargo şirketleriyle. Ayrı bir hesabı ve ayrı bir API anahtarı vardır.

Asıl risk geliştirmede değil, canlıya geçişteTest ve canlı ortam, entegrasyonlarda genellikle koda sabit yazılan şeylerde farklılık gösterir: kargo şirketi sözleşmeleri, hub kodları, marka adları ve erişim bilgileri.Ortama özel tüm değerleri ilk günden yapılandırma dosyasında tutun. Geliştirme sırasında isteğin içine elle yazılan bir değer, canlıya geçilen ilk gün yaşanan klasik sorunların başında gelir ve tamamen önlenebilir.

Platform nasıl genişletilir?

Genişletme noktası	Ne sağlar?
Kurallar	Siparişlerin nasıl yönlendirileceğini ve kargo şirketinin nasıl seçileceğini kod yazmadan belirlemenizi. Bkz. Sipariş yönlendirme ve Kargo OTOmasyonu.
API	Gösterge Panelinde yapılabilen her şeyi kendi sistemlerinizden yapmanızı.
Webhook’lar	Sistemlerinizin, sürekli sorgulamaya gerek kalmadan olaylara tepki vermesini.
Özel bağlayıcılar	Hazır entegrasyonu olmayan bir sistem için, sizin sunduğunuz endpoint’lere göre OTO’nun geliştirdiği bir bağlayıcı. Bkz. ERP sistemleri.

Sorunsuz çalışan bir entegrasyon tasarlamak

Entegrasyon geliştirmeden önce sistemin üç özelliğini bilmeniz faydalı olur.


Olaylar tekrarlanabilir	Bir webhook birden fazla kez gönderilebilir. Her olayın yalnızca bir kez geleceğini varsaymayın; aynı olayın tekrar işlenmesi bir soruna yol açmasın.
Olaylar sırasız gelebilir	Ağ gecikmeleri sizin durum akışınıza uymaz. Eski bir olay geç geldi diye bir siparişin durumunu asla geri almayın.
Kanallar kısa bir gecikmeyle güncellenir	Stok ve durum bilgisinin satış kanalına ulaşması birkaç saniye sürebilir. Birkaç saniyelik bir fark, sistemin bozulduğunu değil, çalıştığını gösterir.

Yeniden deneme stratejisi, erişim anahtarının yenilenmesi ve imza doğrulama gibi ayrıntılar Hatalar ve istek limitleri ile Webhook olayları sayfalarındadır.

Sonraki adımlar

Temel kavramlar

Bu parçaların kullandığı kavramlar.

Geliştiriciler

Her şeyin altındaki API.

Güvenlik ve uyumluluk

Sertifikalar, verinin konumu ve güvenlik kontrolleri.

Başlarken

Modüller

Entegrasyonlar

Geliştiriciler

Platform

Fiyatlandırma

Platform mimarisi

Dört arayüz, tek platform

Veri platforma nasıl girer ve çıkar?

Her şey siparişin etrafında döner

Neler birbirinden ayrı tutulur?

Platform nerede çalışır?

Ortamlar

Platform nasıl genişletilir?

Sorunsuz çalışan bir entegrasyon tasarlamak

Sonraki adımlar

Temel kavramlar

Geliştiriciler

Güvenlik ve uyumluluk

​Dört arayüz, tek platform

​Veri platforma nasıl girer ve çıkar?

​Her şey siparişin etrafında döner

​Neler birbirinden ayrı tutulur?

​Platform nerede çalışır?

​Ortamlar

​Platform nasıl genişletilir?

​Sorunsuz çalışan bir entegrasyon tasarlamak

​Sonraki adımlar

Temel kavramlar

Geliştiriciler

Güvenlik ve uyumluluk

Dört arayüz, tek platform

Veri platforma nasıl girer ve çıkar?

Her şey siparişin etrafında döner

Neler birbirinden ayrı tutulur?

Platform nerede çalışır?

Ortamlar

Platform nasıl genişletilir?

Sorunsuz çalışan bir entegrasyon tasarlamak

Sonraki adımlar