Tracking API mi Shipping API mi: E-ticaret altyapınız hangisine ihtiyaç duyuyor (ya da ikisine birden)?

E-ticaret altyapınızın gönderi oluşturması ve kargo etiketleri üretmesi gerektiğinde bir shipping API kullanın. Gönderiler dağıtıma çıktıktan sonra takip edilmesi ve taşıyıcı güncellemelerinin operasyonel ya da müşteriye yönelik faydalı bilgilere dönüştürülmesi gerektiğinde bir tracking API kullanın. Yazılımınızın gönderi oluşturmayı ve satın alma sonrası görünürlüğü yönetmesi gerekiyorsa her iki yeteneğe de ihtiyacınız vardır; ancak mutlaka iki sağlayıcıya veya iki ayrı entegrasyona ihtiyacınız yoktur.

Karar, fulfillment mimarinize sahip olan kişiye aittir: genellikle bir mühendislik ekibiyle çalışan e-ticaret operasyonları sorumlusuna. Mağazanızın, deponuzun veya fulfillment ortağınızın halihazırda neleri yönettiğini belirleyerek başlayın. Başka bir API eklemek, zaten çalışan bir iş akışını tekrarlamak yerine belirli bir boşluğu kapatmalıdır.

Tracking API ile shipping API arasındaki fark nedir?

Temel ayrım, ürün kategorileri arasında katı bir sınırdan ziyade her API'nin gerçekleştirdiği işle ilgilidir. Bir shipping platformu tracking uç noktaları içerebilirken bir tracking hizmeti bildirimler ve müşteriye yönelik teslimat güncellemeleri için araçlar sağlayabilir. Ürün adına güvenmek yerine belgelenmiş uç noktaları ve olay davranışını değerlendirin.

Karar boyutu	Tracking API	Shipping API
Temel görev	Gönderi durumunu ve takip olaylarını almak veya teslim almak.	Gönderiler oluşturmak ve etiketler ile ilgili kargo belgelerini almak.
Tipik girdiler	Takip numarası, taşıyıcı tanımlayıcısı ve gerekli diğer gönderi bilgileri.	Gönderici ve alıcı bilgileri, paket bilgileri, hizmet seçimi ve geçerli gümrük verileri.
Tipik çıktılar	Gönderi durumu, olay geçmişi ve mevcut diğer teslimat bilgileri.	Gönderi tanımlayıcıları, etiketler ve desteklenen belgeler.
Ana iş akışı	Teslimat görünürlüğü, istisna yönetimi ve satın alma sonrası güncellemeler.	Depodan çıkış ve gönderinin sevke hazırlanması.
Varsayılmaması gereken	Takip erişiminin etiket oluşturmayı veya taşıyıcı rezervasyonunu içerdiği.	Etiket oluşturmanın ihtiyaç duyduğunuz takip derinliğini ve bildirim kontrollerini içerdiği.

Taşıyıcı belgeleri bu ayrımı gösterir. FedEx, gönderi oluşturmayı Ship API belgelerinde, takip yeteneklerini ise tracking API belgelerinde açıklar. Bunlar, belirli bir taşıyıcıyı seçme önerisi değil, farklı teknik sorumluluklara örnektir.

Gönderi oluşturmak, hareketini izlemekle aynı şey değildir

Başarılı bir gönderi oluşturma yanıtı, yazılımınıza bir kargo talebinin işlendiğini bildirir. Taşıyıcının paketi fiziksel olarak teslim aldığını göstermez. Aynı şekilde, takip geçmişinde hareket görünmeden önce de bir takip numarası mevcut olabilir.

Bu nedenle sipariş yönetim sisteminiz etiket oluşturma, devir teslim, taşıyıcının kabulü ve teslimat durumlarını birbirinden ayırmalıdır. Bunların tümünü tek bir “gönderildi” olayı olarak ele almak, müşterilere erken gönderilen mesajlara ve depodan gerçekten çıkmamış paketlerin gözden kaçmasına yol açabilir.

Mevcut darboğazınızı çözen yeteneği seçin

Eksik olan parça sevkiyatsa bir shipping API seçin

Kendi uygulamanızın sipariş verilerini bir gönderiye dönüştürmesi gerektiğinde shipping API uygun başlangıç noktasıdır. Örneğin depo ekibinin adresleri taşıyıcı portallarına elle kopyalaması veya özel bir sipariş yönetim sisteminin etiket üretememesi bu duruma örnektir.

Bir entegrasyon seçmeden önce gerçek sevkiyat iş akışını tanımlayın. Yalnızca gönderi oluşturmanız mı gerekiyor, yoksa ücret sorgulama, iptal, teslim alma talepleri, gümrük belgeleri veya gün sonu işlemleri de gerekli mi? Bu işlevler ayrı API'ler olabilir, taşıyıcıya bağlı olabilir veya ek hesap izinleri gerektirebilir. “Shipping API” etiketli bir ürünün her kargo işlemini içerdiğini varsaymayın.

Tek çözüm olarak ideal değildir: müşteri hizmetleri ekibinizi tek tek taşıyıcı web sitelerini kontrol etmek zorunda bırakan bir etiket oluşturma entegrasyonu. Sevkiyat sorununu çözebilir, ancak teslimat görünürlüğünü büyük ölçüde değiştirmeyebilir.

Gönderi oluşturma zaten çalışıyorsa bir tracking API seçin

Etiketler depo yönetim sisteminiz, fulfillment ortağınız, pazaryeriniz veya mevcut shipping entegrasyonunuz tarafından zaten oluşturuluyor, ancak teslimat bilgileri dağınık durumdaysa tracking API daha doğrudan bir çözümdür.

Bu durumda etiket iş akışını değiştirmek, temel sorunu çözmeden geçiş çalışması yaratabilir. Bunun yerine, üst sistemde oluşturulan takip numaralarını sipariş yönetim sisteminizin, destek araçlarınızın ve müşteri iletişiminizin kullanabileceği bir görünürlük katmanına bağlayın.

Bu kategori için 17TRACK Tracking API uygun bir entegrasyon seçeneğidir. resmi API belgeleri, push bildirimleri de dahil olmak üzere takip numarası kaydı ve takip verisi iş akışlarını açıklar. Bu iş akışlarını gerekli taşıyıcılarınız, gönderi türleriniz ve uygulama mimarinizle karşılaştırarak değerlendirin. Bu, takip katmanıyla ilgili bir değerlendirmedir; hizmetin etiket oluşturma entegrasyonunun yerini aldığı anlamına gelmez.

Tek çözüm olarak ideal değildir: yazılımınızın sevk etmekle sorumlu olduğu gönderileri oluşturmak için hâlâ hiçbir yöntemi yokken bir tracking API kullanmak. Takip görünürlüğü, eksik kargo operasyonunu çözmez.

Uygulamanız sevkiyat ve teslimat görünürlüğünün sahibi olduğunda ikisini de kullanın

Altyapınızın etiket üretmesi ve ardından gönderi ilerlemesini güvenilir biçimde izlemesi gerektiğinde her iki yetenek de uygundur. Bunlar tek bir platformdan, ayrı hizmetlerden veya taşıyıcı entegrasyonları ile bir takip katmanının birleşiminden sağlanabilir.

Shipping ve tracking işlevleri belgelenmiş gereksinimlerinizi gereksiz tavizler olmadan karşılıyorsa tek entegrasyonu tercih edin. Mevcut bir shipping iş akışını korumaya değer olduğunda veya takip gereksinimleri bu iş akışının sağladıklarından önemli ölçüde farklı olduğunda ayrı entegrasyonları değerlendirin. Ayrı bir takip sağlayıcısı otomatik olarak daha iyi değildir; ek entegrasyon, faturalandırma ve operasyonel sahipliği haklı çıkarmalıdır.

Her iki API bir e-ticaret altyapısına nasıl uyum sağlar?

Uygulanabilir bir tasarımda sipariş, gönderi ve takip olayı ayrı kayıtlar olarak tutulur. Bir sipariş birkaç paket oluşturabilir ve her paketin kendi takip geçmişi olabilir. Müşteriye gösterilen sipariş durumu, bu kayıtların üzerine yazılmak yerine gönderi kayıtlarından türetilmelidir.

1. Sipariş fulfillment için hazır hale gelir. Mağaza veya sipariş yönetim sistemi, gerekli fulfillment verilerini sorumlu depoya gönderir.
2. Shipping iş akışı gönderiyi oluşturur. Uygulama, dönen gönderi tanımlayıcısını, takip numarasını, taşıyıcıyı, hizmeti ve etiket referansını saklar.
3. Depo devir teslimi tamamlar. Depo onayı ile taşıyıcının kabulü birbirinden ayırt edilebilir olaylar olarak kalır.
4. Takip iş akışı başlar. Uygulamanız, seçilen entegrasyonun gerektirdiği şekilde takip numarasını kaydeder veya gönderir.
5. Takip güncellemeleri uygulamanıza ulaşır. Webhook'lar, yoklama veya desteklenen bir kombinasyon gönderi kaydını besler.
6. İş kuralları sonraki adımı belirler. Sisteminiz, ilgili koşullar karşılandığında müşteriye gösterilen durumu günceller, operasyonel bir görev oluşturur veya mesaj gönderir.

Örneğin üçüncü taraf bir fulfillment deposu kullanan bir satıcının kendi yazılımında yalnızca dördüncü ile altıncı adımlara ihtiyacı olabilir. Gönderi oluşturma işlemi zaten deponun sorumluluğundadır. Kendi deposunu işleten bir satıcının ise tüm akışa ihtiyacı olabilir.

Her sonraki işlem için tek bir sorumlu belirleyin

Her iki entegrasyon da takip güncellemeleri sağlıyorsa müşteri bildirimlerini ve mağazanızda gösterilen gönderi durumunu hangi sistemin kontrol edeceğini belirleyin. Aksi halde müşteriler yinelenen mesajlar alabilir veya çelişkili teslimat durumları görebilir.

Her kaynağın e-posta tetiklemesine izin vermeden ikincil verileri inceleme amacıyla saklayabilirsiniz. Desteğin, sistemin bir gönderiyi neden belirli bir şekilde sınıflandırdığını anlayabilmesi için orijinal taşıyıcı olayını dahili durum eşleştirmenizin yanında koruyun.

Özellik etiketlerini değil, operasyonel uyumu karşılaştırın

Gerçekte kullandığınız taşıyıcıları ve hizmetleri doğrulayın

Taşıyıcı desteği tek bir evet-hayır sorusu değildir. Bir hizmet, bir taşıyıcı için takibi desteklerken aynı taşıyıcı için etiket oluşturmayı desteklemeyebilir. Etiket oluşturma ayrıca çıkış ülkesine, taşıyıcı hesabı kurulumuna veya hizmet uygunluğuna bağlı olabilir.

Gerçek kargo rotalarınızdan bir test listesi oluşturun. Yurtiçi paketleri, uluslararası gönderileri ve taşıma ortakları arasındaki devir teslimleri dahil edin. Her biri için gerekli işlemi (gönderi oluşturma, takip veya her ikisi) doğrulayın. Geniş kapsam beyanı, işletmenizin güvendiği hizmetlerin başarılı testlerinden daha az kullanışlıdır.

Olay anlamını ve veri bütünlüğünü inceleyin

Takip için ilk taramadan önce, teslimat istisnası sırasında, başarısız teslimat girişiminden sonra ve teslimat anında ne olduğunu test edin. Zaman damgalarının saat dilimi bilgisi içerip içermediğini ve orijinal taşıyıcı açıklamalarının kullanılabilir kalıp kalmadığını kontrol edin.

Normalleştirilmiş bir durumu, tüm taşıyıcılarda aynı verinin sunulacağının garantisi olarak yorumlamayın. Tahmini teslimat tarihleri, konum ayrıntıları ve teslimat kanıtı bilgileri, temel taşıyıcıya ve gönderiye bağlı olabilir. Bu alanlar bulunmadığında arayüzünüzün nasıl davranacağına karar verin.

Her iki tarafta da hata kurtarmayı kontrol edin

Shipping tarafında, gönderi oluşturma sırasında yaşanan zaman aşımına özel önem verin: uygulamanız yanıtı almasa bile istek başarılı olmuş olabilir. Körlemesine yeniden denemeden önce sağlayıcının desteklediği yinelenen gönderi önleme ve mutabakat mekanizmalarını doğrulayın.

Tracking tarafında yinelenen bildirimleri, gecikmiş olayları, başarısız webhook teslimini ve geçici uç nokta kesintilerini test edin. İlgili belgelerde kimlik doğrulamayı, yeniden deneme davranışını ve kurtarma seçeneklerini doğrulayın. Bir güncellemenin yeniden oynatılması aynı müşteri bildirimini tekrar göndermeyecek şekilde olay işlemeyi tasarlayın.

Bir fiyatlandırma modeli varsaymadan toplam işletme maliyetini karşılaştırın

API ücretlerini posta ve taşıyıcı hesabı ücretlerinden ayırın. Shipping ve tracking hizmetleri farklı faturalandırma birimleri kullanabilir ve birleşik bir platform yetenekleri farklı şekilde paketleyebilir. Gerçekleştirmeyi planladığınız iş akışı için teklif alın veya geçerli planı inceleyin.

Faturalandırılabilir kullanımın nasıl tanımlandığını, başarısız isteklerin sayılıp sayılmadığını, yinelenen takip gönderimlerinin nasıl ele alındığını ve kullanım bir kotayı aştığında ne olduğunu sorun. Mühendislik bakımını, destek çabasını ve iki entegrasyonu tutarlı tutmanın maliyetini de dahil edin. Tanımlanmış bir gönderi karması ve güncel ticari koşullar olmadan bir kategorinin daha ucuz olduğunu ilan etmek yanıltıcı olur.

Güvenlik ve veri saklamayı inceleyin

Shipping entegrasyonları alıcı adreslerini ve gümrük bilgilerini işleyebilir. Tracking entegrasyonları da gönderi tanımlayıcılarını ve bunlarla ilişkili müşteri verilerini işleyebilir. Hangi alanların gerekli olduğunu doğrulayın, kimlik bilgilerini gerekli erişimle sınırlayın ve gizli bilgileri tarayıcı tarafındaki koddan uzak tutun.

Saklama, silme ve erişim kontrollerini işletme gereksinimlerinizle karşılaştırarak inceleyin. Kullanışlı bir entegrasyon, iş akışının ihtiyaç duymadığı müşteri bilgilerinin gönderilmesini gerektirmemelidir.

Karar vermeden önce uygulanabilir bir doğrulama planı

Yalnızca hızlı başlangıç kılavuzundaki başarılı bir örnek yerine, gerçeği temsil eden gönderilerle bir kavram kanıtı çalıştırın. Operasyon, mühendislik ve müşteri desteğiyle kabul kriterleri üzerinde anlaşın.

• Sevkiyat: gerekli etiket biçimlerini oluşturun ve depo ekipmanının bunları kullanabildiğini doğrulayın.
• Sipariş eşleştirme: orijinal geçmişi kaybetmeden bölünmüş gönderileri, birden fazla paketi ve değiştirme gönderilerini test edin.
• Takip: işletmeniz için önemli taşıyıcılar ve rotalarla ilgili gerçek olay dizilerini kontrol edin.
• İstisnalar: uygulanabilir bir teslimat sorununun, her olağandışı taramayı otomatik olarak hata olarak değerlendirmeden doğru ekibe ulaştığını doğrulayın.
• Kurtarma: bir isteği veya webhook uç noktasını kesintiye uğratın ve uygulamanın eksik bilgileri nasıl uzlaştırdığını gösterin.
• İletişim: her müşteri bildirimini yalnızca belirlenen sistemin gönderdiğini doğrulayın.
• Ticari uyum: beklenen kullanımınız ve sağlayıcının doğrulanmış faturalandırma tanımlarıyla ücretleri tahmin edin.

Karar kuralı: önce eksik yeteneği satın alın. Sevkiyat zaten çalışıyorsa fulfillment'ı yeniden oluşturmadan bir tracking entegrasyonunu değerlendirin. Etiket oluşturma eksikse önce kargo operasyonunu çözün. Uygulamanız tüm gönderi yaşam döngüsünün sahibiyse her iki yeteneği de doğrulayın ve birleşik ya da ayrılmış mimarilerden hangisinin ekibiniz tarafından daha kolay işletileceğine karar verin.

SSS

Bir shipping API her zaman tracking içerir mi?

Hayır. Bazı hizmetler her iki yeteneği de içerirken bazıları bunları ayrı uç noktalar, ürünler veya planlar üzerinden sunar. Tracking dahil olsa bile, bunu satın alma sonrası takip çözümünüz olarak değerlendirmeden önce olay ayrıntısını, güncelleme iletim yöntemini, taşıyıcı desteğini ve kullanım koşullarını doğrulayın.

Etiketleri bir fulfillment ortağı tarafından oluşturulan paketleri takip edebilir miyim?

Potansiyel olarak evet. Uygulamanız, genellikle takip numarası ve gerektiğinde taşıyıcı tanımlayıcısı veya ek doğrulama bilgileri dahil olmak üzere tracking entegrasyonunun gerektirdiği tanımlayıcılara ihtiyaç duyar. Ortağın taşıyıcıları için desteği doğrulayın ve takip numaralarının sisteminize güvenilir biçimde aktığından emin olun.

Bir tracking API taşıyıcı taramalarının daha erken gerçekleşmesini sağlar mı?

Fiziksel taşıyıcı taramaları oluşturamaz. Takip kaynakları aracılığıyla sunulan bilgileri uygulamanızın almasına, düzenlemesine ve dağıtmasına yardımcı olabilir. Bir API'nin her hareket için anında görünürlük garantilediğini varsaymak yerine güncelleme davranışını gerçek gönderilerle değerlendirin.

Her iki yeteneği kullanmak için iki API sağlayıcısına ihtiyacım var mı?

Hayır. İki satıcıya değil, her iki işleve ihtiyacınız vardır. Shipping ve tracking gereksinimlerinizi karşılıyorsa tek sağlayıcı kullanın. Bunu yapmak çalışan bir iş akışını koruyorsa veya birleşik seçeneğin karşılamadığı belirli bir gereksinimi karşılıyorsa bunları ayırın.

Bir tracking API sipariş yönetim sisteminin yerini alabilir mi?

Hayır. Tracking verileri sipariş yönetimine yönelik bir girdidir; envanter tahsisi, fulfillment kararları, ödeme işlemleri veya sipariş kayıtlarının yerine geçmez. Uygulamanızın her gönderiyi doğru siparişle ilişkilendirmesi ve gönderi olaylarının iş akışlarını nasıl etkileyeceğine karar vermesi gerekir.

Kaynaklar

• FedEx Ship API belgeleri — gönderi oluşturma, etiketler ve shipping iş akışı gereksinimleri için referans.
• FedEx tracking API belgeleri — takip istekleri ve gönderi durumu bilgileri için referans.
• 17TRACK Tracking API — tracking entegrasyonu kategorisi için resmi ürün referansı.
• 17TRACK API belgeleri — takip kaydı, takip verileri ve push bildirimi entegrasyonu için referans.