Tek Bir API ile Çin'den Avrupa'ya ve ABD'ye Gönderiler Nasıl Takip Edilir

Çin'den Avrupa'ya ve ABD'ye gönderileri tek bir API ile takip etmek için sipariş sisteminizi çoklu taşıyıcılı bir takip hizmetine bağlayın, her paketi takip numarası ve gerekli taşıyıcı bilgileriyle kaydedin ve takip güncellemelerini ortak bir gönderi kaydına aktarın. Entegrasyon; uluslararası aktarmaları, gecikmiş taramaları ve ayrı son kilometre takip numaralarını dikkate almalıdır. Tek bir API, takip bilgilerine erişimi birleştirebilir; ancak taşıyıcının bildirmediği olayları oluşturamaz.

Geliştiriciler ve e-ticaret operasyon ekipleri için amaç yalnızca bir durum görüntülemek değildir. Amaç, her fiziksel paketi doğru siparişle ilişkilendirmek, müşterileri yanıltıcı güncellemeler göndermeden bilgilendirmek ve müdahale gerektiren gönderileri belirlemektir. Bu kılavuz, bu iş akışının nasıl oluşturulacağını ve 17TRACK Tracking API gibi bir hizmetin gerçek gönderim rotalarınıza göre nasıl değerlendirileceğini açıklar.

Yalnızca varış ülkesinden değil, gönderim rotasından başlayın

Çin'den Avrupa'daki veya ABD'deki bir adrese giden bir paket; toplama hizmeti, uluslararası taşıma ağı, gümrük işlemleri ve varış noktası teslimat taşıyıcısından geçebilir. Bazı gönderim hizmetleri bu hareketleri tek bir takip numarası altında sunar. Diğerleri ise yolculuğun ilerleyen aşamalarında ayrı bir teslimat referansı sağlar.

Bu nedenle entegrasyonu doğrulamak için ülke düzeyindeki kapsama yeterli değildir. Bir sağlayıcı bir taşıyıcıyı tanıyabilir ancak belirli bir gönderim ürünü için ihtiyacınız olan tüm olayları döndürmeyebilir. Benzer şekilde, çıkış taraması varış teslimatı taramalarının kullanılabilir olacağını göstermez.

Entegrasyon öncesinde, işletmenizin gerçekten gönderdiği gönderileri kullanarak bir rota envanteri oluşturun. Çıkış lojistik sağlayıcısını, gönderim hizmetini, varış pazarını, bilinen teslimat taşıyıcısını ve takip numarası biçimlerini kaydedin. Bir ülkedeki başarılı teslimatın bölge genelinde kapsama olduğunu varsaymak yerine, testler sırasında Avrupa pazarlarını ayrı ayrı ele alın.

• Operasyonlar için: Takip boşluklarının şu anda nerelerde manuel iş veya müşteri iletişimi oluşturduğunu belirleyin.
• Mühendislik için: Hangi sistemlerin gönderi oluşturduğunu ve hangi sistemlerin güncellemelere ihtiyaç duyduğunu belirleyin.
• Satın alma için: Rota envanterindeki belirli taşıyıcılar ve hizmetler için desteği doğrulayın.

Tek bir takip API'si ne yapmalı—ve ne yapamaz?

Çoklu taşıyıcılı bir Tracking API, uygulamanızın her taşıyıcı bağlantısını ayrı ayrı yönetmesini gerektirmek yerine ortak bir entegrasyon katmanı sağlar. Hizmete ve entegrasyon yöntemine bağlı olarak uygulamanız güncellemeleri alabilir, geri çağrılar alabilir veya her ikisinin birleşimini kullanabilir. Üretim iş akışınızı tasarlamadan önce desteklenen mekanizmaları sağlayıcının belgelerinde doğrulayın.

Kullanışlı soyutlama, tutarlı bir gönderi modelidir. Sipariş yönetim sisteminizin her taşıyıcının ifadeleri için farklı iş mantığına ihtiyaç duymaması gerekir; ancak destek ve inceleme amacıyla orijinal bilgileri korumalıdır.

Birleştirilmiş takip, sürekli fiziksel görünürlük, teslimat tahmini veya eksiksiz gümrük geçmişi garantisi vermez. Taşıyıcının bildirecek yeni bir taraması yokken API bağlantısı sağlıklı olabilir. Takip; gönderi etiketi satın alma, gümrük beyannamelerini hazırlama ve teslimat hizmetlerini ayarlama işlemlerinden de ayrıdır. Bu işlevlerin dahil olduğunu varsaymayın.

Entegrasyonu paket düzeyinde bir kayıt etrafında oluşturun

1. Siparişleri, gönderileri ve takip tanımlayıcılarını ayırın

Tek bir e-ticaret siparişi birkaç paket içerebilir ve bu paketler farklı zamanlarda ulaşabilir. Sabit tanımlayıcınız olarak dahili bir paket veya gönderi ID'si kullanın. Müşterinin siparişini bu kayıtla ilişkilendirin, ardından taşıyıcı takip tanımlayıcılarını buna ekleyin.

Uygulanabilir bir dahili model şunları içermelidir:

• Dahili sipariş ID'si ve paket ID'si.
• Orijinal takip numarası ve API tarafından kullanılan taşıyıcı tanımlayıcısı.
• Doğrulanmış tüm varış taşıyıcısı takip numaraları.
• Gönderim hizmeti ve varış ülkesi.
• Mevcut normalleştirilmiş durum ve orijinal taşıyıcı açıklaması.
• Olay zamanı, sağlandığında olay konumu ve sisteminizin güncellemeyi aldığı zaman.
• Kayıt durumu, son başarılı senkronizasyon ve çözülmemiş entegrasyon hataları.

Bunlar önerilen uygulama alanlarıdır; her sağlayıcının bunları döndürdüğü iddia edilmemektedir. Gelecekteki bir API değişikliğinin sipariş veritabanınızı yeniden tasarlamanızı gerektirmemesi için dahili şemanızı sağlayıcının yanıt biçiminden ayrı tutun.

2. Paketleri güvenilir bir iş olayından kaydedin

Takip numarası bir pakete atandığında takip kaydı oluşturun; biri sipariş sayfasını görüntülediğinde değil. Deponuzdan veya sipariş sisteminizden gelen gönderi oluşturuldu olayı genellikle daha iyi bir tetikleyicidir. Bir etiket geçersiz kılınır veya değiştirilirse, terk edilmiş numarayı tek takip referansı olarak bırakmak yerine paketin tanımlayıcı ilişkilerini güncelleyin.

Numaranın mevcut olduğunu ve elektronik tablo biçimlendirmesi nedeniyle bozulmadığını doğrulayın. Anlamlı baştaki sıfırları koruyun. Gönderim sisteminiz taşıyıcıyı biliyorsa, otomatik tanımlamaya tamamen güvenmek yerine bu bilgiyi saklayın: numara biçimleri çakışabilir.

Kayıt yanıtını tek tek gönderi düzeyinde okuyun. Başarılı bir HTTP isteği, toplu işlemdeki her öğenin kabul edildiğini zorunlu olarak göstermez. Hataları bir yeniden deneme kuyruğunda saklayın ve operasyon ekibine geçersiz veya belirsiz gönderimleri çözebileceği bir yol sağlayın.

3. Müşteri bildirimlerine bağlanmadan önce güncelleme teslimatını tasarlayın

Seçilen hizmet web kancalarını destekliyorsa güncellemeleri almak için belgelenmiş geri çağrı mekanizmasını kullanın. Bir doğrulama başlığı icat etmek yerine mevcut kimlik doğrulama veya imza yöntemini doğrulayın. Kimlik bilgilerini sunucuda tutun, HTTPS zorunlu kılın ve API gizli anahtarlarını tarayıcı koduna veya müşteriye açık bağlantılara dahil etmekten kaçının.

Alıcınız bir güncellemeyi onaylamadan önce kalıcı olarak kabul etmeli, ardından güncellemeyi eşzamansız şekilde işlemelidir. Yinelenen teslimatlar ve sırası dışında gelen olaylar için tasarım yapın. Kullanılabilir olduğunda sağlayıcı olay ID'sini kullanın; aksi takdirde sabit olay özelliklerini kullanarak belgelenmiş bir tekilleştirme kuralı tanımlayın.

Yoklama gerekiyorsa bunu sağlayıcının belgelenmiş sınırları ve operasyonel ihtiyaçlarınız dahilinde planlayın. Hız sınırı yanıtlarından sonra beklemeyi artırın, eş zamanlı yeniden deneme artışlarından kaçının ve saklama ve mutabakat politikanıza göre tamamlanmış gönderilerde gereksiz kontrolleri durdurun. Planlanmış bir mutabakat görevi, hizmetin alınmasına izin verdiği durumlarda kaçırılan güncellemeleri tespit etmeye de yardımcı olabilir.

4. Anlamı kaybetmeden durumları normalleştirin

Sipariş sisteminizin ve destek ekibinizin tutarlı biçimde yorumlayabileceği küçük bir dahili durum kümesi kullanın. Örnekler arasında bilgi alındı, taşıma halinde, teslimat için çıktı, teslim edildi, teslimat istisnası ve iade edildi bulunur. Bunlar önerilen uygulama kategorileridir; herhangi bir sağlayıcının kesin durum kodlarının açıklaması değildir.

Ayrıntılı taşıyıcı olayını normalleştirilmiş durumla birlikte saklayın. Başarısız teslimat girişimi, adres sorunu ve gümrükle ilgili gecikmenin tümü müdahale gerektirebilir; ancak aynı yanıtı gerektirmez. Her şeyi genel bir istisnaya eşlemek verilerin saklanmasını kolaylaştırır, ancak eyleme dönüştürülmesini zorlaştırır.

Etiket oluşturmayı fiziksel teslim alma olarak çevirmeyin. Benzer şekilde, bir olayda gümrük tesisi geçiyor diye paketi gümrükten geçmiş olarak etiketlemeyin. Olayın gerçek anlamına uygun bir dil kullanın.

Uluslararası aktarmaları açıkça yönetin

En önemli entegrasyon testi çoğu zaman çıkış ağı ile varış teslimatı arasındaki geçiştir. Hem orijinal referansı hem de doğrulanmış son kilometre referansını koruyun. Yeni takip numarası aynı paket için başka bir tanımlayıcı olmalı, otomatik olarak ikinci bir gönderi olmamalıdır.

Tanımlayıcıları yalnızca lojistik sağlayıcısı, takip yanıtı veya gönderim sisteminiz gibi güvenilir bir kaynaktan gelen ilişkiye dayanarak bağlayın. Benzer olay zamanları veya eşleşen varış ülkeleri, iki numaranın aynı pakete ait olduğunu kanıtlamak için yeterli değildir.

Olay zamanını sisteme alınma zamanından ayrı tutun. Özellikle bilgiler ağlar arasında hareket ederken daha eski bir olay, daha yeni bir olaydan sonra sisteminize ulaşabilir. Sağlanan saat dilimi farklarını koruyun, zaman damgalarını işleme için normalleştirin ve desteklenmeyen bir saat dilimi atamak yerine belirsiz kaynak değerlerini saklayın.

Müşteriler için en son anlamlı durumu görünür bir güncelleme zamanıyla gösterin. Varış taşıyıcısı henüz bir tarama bildirmediyse takibin başka bir güncelleme beklendiğini açıklayın. Paketin kaybolduğunu, son tarama konumunda fiziksel olarak hâlâ bulunduğunu veya varış ülkesinde olduğunu varsaymayın.

17TRACK bu iş akışına nasıl uyuyor?

17TRACK'in Tracking API teklifi, uygulamanızın çoklu taşıyıcılı bir takip entegrasyonuna ihtiyaç duyduğu durumlarda uygundur. resmî API belgeleri; kimlik doğrulama, kayıt, yanıt işleme ve desteklenen güncelleme iş akışlarının uygulanmasına rehberlik etmelidir. Tüketici takip sayfasını entegrasyon arayüzü olarak değerlendirmek yerine belgelenmiş API sözleşmesini kullanın.

Bunu kendi uygulamanız için geçerli kılacağınız operasyonel gereksinimlerle değerlendirin: doğru taşıyıcı tanımlama, rotalarınızda yararlı olaylar, aktarma sürekliliği, hata kurtarma ve yönetilebilir güncelleme teslimatı. Üretim tasarımına karar vermeden önce ticari koşulları, kullanım hesaplamasını, istek sınırlarını ve gerekli hesap yapılandırmasını doğrulayın.

Birleştirilmiş API seçmenin en güçlü nedeni, gerçekten işlettiğiniz rotalar için entegrasyon karmaşıklığının azalmasıdır. Bu avantajın yine de temsili paketlerle doğrulanması gerekir. Hiçbir sağlayıcı yalnızca genel kapsama açıklaması geniş göründüğü için seçilmemelidir.

Yayına almadan önce rota tabanlı bir pilot yürütün

Normal teslimatları ve zor durumları içeren bir test seti kullanın. Geçmiş gönderiler durum eşlemesini test etmeye yardımcı olurken canlı gönderiler güncelleme teslimatını ve operasyonel zamanlamayı ortaya çıkarır. Tek başına hiçbir test her soruyu yanıtlamaz.

• Çin-ABD teslimatı: Çıkış olaylarını, varsa uluslararası aktarmayı ve son teslimat olayını doğrulayın.
• Çin-Avrupa teslimatları: Gerçekte kullandığınız varış ülkelerini ve gönderim hizmetlerini test edin.
• Yeni etiket: Fiziksel taraması olmayan bir paketin hareket halinde gösterilmediğini doğrulayın.
• Değişen teslimat referansı: İlişkinin doğru pakete bağlı kaldığını doğrulayın.
• Teslimat istisnası: Ayrıntılı nedenin uygun operasyon kuyruğuna ulaştığını kontrol edin.
• Bölünmüş sipariş: Bir paketin teslim edilmesinin tüm siparişi kapatmadığını doğrulayın.
• Yinelenen veya gecikmiş güncelleme: Tekrarlanan mesajlar oluşturmadığını veya daha yeni bir durumu yanlışlıkla ezmediğini doğrulayın.
• Geçici entegrasyon hatası: Yeniden deneme, mutabakat ve destek görünürlüğünü doğrulayın.

Sonuçları incelemeden önce kabul kriterlerini belirleyin. Kayıt başarısını, yanlış taşıyıcı atamalarını, eksik kilometre taşlarını, güncelleme işleme gecikmelerini ve yinelenen müşteri mesajlarını ölçün. Desteklenmeyen evrensel bir ölçütü kopyalamak yerine işletmeniz için kabul edilebilir eşikleri tanımlayın. Eksik bir olayı API'ye bağlamadan önce taşıyıcının kendi kaydına göre inceleyin.

Veri güncelliğini API kullanılabilirliğinden ayrı izleyin

API Monitoring iki farklı soruyu yanıtlamalıdır: entegrasyon çalışıyor mu ve gönderi bilgileri yararlı mı? Başarılı istekler yalnızca ilk soruyu yanıtlar. Ayrıca kayıtların hata biriktirip biriktirmediğini, geri çağrıların başarısız olup olmadığını veya bir rotanın beklenen kilometre taşlarını üretmeyi bırakıp bırakmadığını bilmeniz gerekir.

• Entegrasyon sağlığı: Kimlik doğrulama hataları, istek hataları, hız sınırı yanıtları, geri çağrı hataları ve kuyruk birikmeleri.
• Veri kalitesi: Bilinmeyen durumlar, hatalı zaman damgaları, çözümlenmemiş taşıyıcı kimlikleri ve beklenmeyen tanımlayıcı değişiklikleri.
• Gönderi güncelliği: Rota ve gönderim hizmetine göre ayrıştırılmış, son taşıyıcı olayından bu yana geçen süre.
• İş etkisi: İstisna iş yükü, başarısız bildirimler ve yanlışlıkla tamamlandı olarak işaretlenen siparişler.

Bir tarama olmadan geçen uzun süre bir gönderim hizmetinde normal, diğerinde olağandışı olabilir. İncelemelere öncelik vermek için rotaya özgü beklentileri ve gözlemlenen gönderi geçmişini kullanın. Doğru ekibin alabilmesi için entegrasyon hatası uyarısını gönderi gecikmesi uyarısından ayrı tutun.

Müşteri bildirimleri her ham olayı değil, doğrulanmış kilometre taşlarını izlemelidir. Yinelenenleri bastırın, teslimat girişimini tamamlanmış teslimattan ayırın ve temel verilerin desteklemediği varış tarihleri vadetmekten kaçının. Takip yüklerine erişimi sınırlayın ve kişisel bilgileri yalnızca iş akışınızın gerektirdiği ölçüde saklayın.

SSS

Tek bir API hem Çin'deki çıkış taşıyıcısını hem de varış teslimat taşıyıcısını takip edebilir mi?

Çoklu taşıyıcılı bir hizmet, ilgili hizmetler ve tanımlayıcı ilişkileri desteklendiğinde yolculuğun her iki bölümündeki olayları birleştirebilir. Tüm rotayı gerçek paketlerle doğrulayın. Çıkış takip numarasının tanınması, varış teslimatı bilgilerinin kullanılabilir olacağını tek başına kanıtlamaz.

Bir paket Çin'den ayrıldıktan sonra takip neden güncellenmeyi durdurur?

Olası nedenler arasında fiziksel taramalar arasındaki boşluk, gecikmiş bildirim veya başka bir teslimat referansına aktarma bulunur. Ham olayları ve sağlanan son kilometre numarasını kontrol edin, ardından ilgili taşıyıcının kaydıyla karşılaştırın. Takip boşluğu tek başına paketin kaybolduğunu veya gümrükte tutulduğunu göstermez.

Uygulama web kancaları mı yoksa yoklama mı kullanmalı?

Sağlayıcınızın belgelerinde açıklanan mekanizmaları kullanın. Desteklendiğinde web kancaları tekrarlanan kontrolleri azaltabilir; izin verilen alma istekleri ise mutabakatı destekleyebilir. Her iki tasarımda da güncellemelere müşteri iletişimlerinde güvenmeden önce yinelenen işlemeyi, yeniden deneme kontrollerini ve izlemeyi oluşturun.

Bir takip API'si teslimat tarihini veya gümrük işlemlerinin tamamlanmasını garanti edebilir mi?

Takip verileri bunların hiçbirini garanti etmez. Tahmini teslimat tarihi sağlanıyorsa kaynağını koruyun ve bunu tahmin olarak sunun. Gümrükle ilgili taramalar, sonucu açıkça belirtmedikçe gümrük işlemlerinin tamamlandığı şeklinde yorumlanmamalı; gerçek ifadelerine göre açıklanmalıdır.

Bir API planı seçmeden önce neler doğrulanmalı?

Taşıyıcılarınızı ve gönderim hizmetlerinizi, kayıt gereksinimlerini, güncelleme yöntemlerini, kullanım hesaplamasını, istek sınırlarını, veri kullanılabilirliğini ve destek düzenlemelerini doğrulayın. Değiştirilen numaraların, yinelenen kayıtların ve geçmiş sorgularının ticari olarak nasıl ele alındığını sorun. Bütçenizi veya mimarinizi etkileyen gereksinimler için güncel belgeleri ve yazılı onayı kullanın.

Kaynaklar

• 17TRACK Tracking API — takip API'si teklifine ilişkin resmî ürün referansı.
• 17TRACK API belgeleri — entegrasyonun uygulanmasına ilişkin resmî teknik referans. Geliştirmeden önce kesin istek biçimlerini, desteklenen iş akışlarını ve sınırları burada doğrulayın.