Tek Bir API ile Avustralya ve Yeni Zelanda'da Gönderi Takibini Nasıl Birleştirebilirsiniz

Avustralya ve Yeni Zelanda genelinde gönderi takibini tek bir API ile birleştirmek için sipariş veya sipariş karşılama sisteminizi çoklu taşıyıcı takip hizmetine bağlayın, her gönderiyi doğru taşıyıcı kimliğiyle kaydedin ve gelen takip güncellemelerini tutarlı bir dahili olay modeline dönüştürün. Entegrasyon, taşıyıcıya özgü ayrıntıları korurken operasyon ekibinize ve müşterilerinize yurt içi ve Tasman Denizi ötesi teslimatlar için tek bir takip deneyimi sunmalıdır.

Geliştiriciler, e-ticaret yöneticileri ve lojistik ekipleri için temel zorluk ilk API isteğini göndermek değildir. Zorluk, farklı taşıyıcılar aynı yolculuğu farklı biçimlerde tanımladığında gönderi kimliklerini, teslimat durumlarını, taşıyıcı devirlerini ve müşteri bildirimlerini tutarlı tutmaktır. Bu kılavuz, bu entegrasyonun nasıl tasarlanacağını, bir takip API'sinin nasıl değerlendirileceğini ve üretimde kullanılmadan önce nasıl test edileceğini açıklar.

Tek API'nin neleri birleştirmesi gerektiğini tanımlayın

Paylaşılan bir API, uygulamanıza ortak bir entegrasyon noktası sağlar. Her taşıyıcının aynı bilgileri yayımlamasını veya paketleri aynı sıklıkta taramasını sağlamaz. Mimarinizin tutarlı bir arayüz ile eksiksiz görünürlük arasındaki farkı ayırt etmesi gerekir.

Her iki ülkede faaliyet gösteren taşıyıcıların genel bir listesinden ziyade gerçek sipariş karşılama faaliyetlerine dayalı bir gönderi envanteriyle başlayın. Avustralya içi gönderileri, Yeni Zelanda içi gönderileri ve her iki yöndeki sınır ötesi hareketleri dahil edin. İşletmenizin parçasıysa diğer uluslararası çıkış noktalarını da ekleyin.

• Taşıyıcı ve hizmet: Taşıyıcıyı, kullanılan hizmeti ve bilinen teslimat ortağını kaydedin.
• Rota: Gönderinin çıkış ve varış noktalarını, son taramanın yapıldığı konumdan ayırın.
• Kimlik bilgileri: Sipariş referansını, sipariş karşılama referansını, takip numarasını ve varsa değiştirme veya iş ortağı numarasını alın.
• Operasyonel amaç: Güncellemelerin müşteri takibini, istisna yönetimini, teslimat onayını veya üçünü birden destekleyip desteklemediğini belirtin.
• Gerekli ayrıntı: Genel bir teslimat durumunun yeterli olup olmadığına veya temsilcilerin tarama açıklamalarına, konumlara ve zaman damgalarına da ihtiyaç duyup duymadığına karar verin.

Bu envanter kabul kontrol listeniz olur. Bir sağlayıcının genel taşıyıcı kapsamı kısa liste oluşturmak için yararlıdır; ancak kararınız, gerçek taşıyıcı-hizmet kombinasyonlarınızın kullanılabilir takip bilgileri döndürüp döndürmediğine dayanmalıdır.

Takip API'sini gönderi karışımınıza göre değerlendirin

17TRACK, çoklu taşıyıcı entegrasyonu için değerlendirmeye uygun bir seçenek olan bir Tracking API sunar. Güncel entegrasyon gereksinimlerini kontrol etmek için resmî API belgelerini kullanın. Taşıyıcı desteğini, olay alanlarını, güncelleme davranışını, hesap sınırlarını ve ticari şartları, ürün kategorisinden çıkarılan varsayımlar olarak değil, uygulamanız için doğrulanması gereken unsurlar olarak ele alın.

Değerlendirdiğiniz her API için aynı pratik soruları sorun:

• Gönderi envanterinizdeki taşıyıcıları ve hizmetleri tanımlayıp takip edebilir mi?
• Taşıyıcı tespiti belirsiz olduğunda açık bir taşıyıcı kimliği sağlayabilir misiniz?
• Uygulamanız güncellemeleri nasıl alıyor ve bir güncelleme kaçırılırsa hangi kurtarma mekanizması mevcut?
• Hangi özgün taşıyıcı ayrıntıları normalleştirilmiş durumların yanında kullanılabilir kalıyor?
• Bir takip numarası geçersiz, henüz tanınmıyor veya birden fazla olası taşıyıcıyla ilişkili olduğunda ne olur?
• Kullanım, faturalandırma, takip süresi ve erişim sınırları hesabınız için nasıl tanımlanıyor?

Önerilen karar kuralı: En büyük başlık taşıyıcı sayısına göre değil, gerçek gönderi modelleriniz üzerinde başarılı testlere göre seçim yapın. Bir entegrasyon, operasyonel kararlarınızı destekleyecek yeterli bilgiyi sağladığında ve hataları kurtarılabilecek kadar açık biçimde gösterdiğinde uygundur.

Taşıyıcı farklılıklarına dayanıklı bir dahili model oluşturun

Siparişleri, gönderileri ve takip aşamalarını ayırın

Takip numarasını sipariş için birincil anahtar olarak kullanmayın. Bir sipariş birkaç paket içerebilir ve bir paketin yolculuğunda birden fazla takip kimliği bulunabilir. Bunun yerine dahili bir gönderi kimliği oluşturun ve takip kayıtlarını buna bağlayın.

Pratik bir modelin üç düzeyi vardır: müşteri siparişi, siparişe ait fiziksel gönderiler ve her gönderiyle ilişkili takip aşamaları. Yurt içi bir paket için yalnızca tek bir takip aşaması yeterli olabilir. Sınır ötesi bir paket için başka bir taşıyıcı veya kimlik önem kazandığında bağlantılı kayıtlar gerekebilir.

Bir takip kaydını takip numarasının yanı sıra taşıyıcı kapsamında da tanımlayın ve gönderi kimliğiyle ilişkisini koruyun. Yeni bir teslimat ortağı numarası ortaya çıkarsa özgün numaranın üzerine yazmak yerine ilgili bir kimlik olarak ekleyin. Bu, destek temsilcilerinin bir devir teslimi incelerken ihtiyaç duyduğu geçmişi korur.

Ham olayı ve normalleştirilmiş olayı ayrı tutun

İşletmenizin eyleme geçebileceği küçük bir dahili durum sözlüğü kullanın. Örneğin taşıma öncesi, taşımada, dağıtıma çıktı, teslim alınmaya hazır, teslim edildi, istisna ve bilinmiyor durumlarını tanımlayabilirsiniz. Bunlar önerilen dahili kategorilerdir; belirli bir sağlayıcının durum şemasına ilişkin bir iddia değildir.

Özgün taşıyıcı açıklamasını eşleştirilmiş durumunuzun yanında saklayın. Teslim alma noktası olayı ile adres sorunu müşterinin eyleme geçmesini gerektirebilir; ancak aynı mesajı üretmemelidir. Benzer şekilde etiket oluşturulması, taşıyıcının paketi fiziksel olarak teslim aldığı anlamına otomatik olarak gelmemelidir.

Eşleme kararlarını sürümlendirilmiş bir yapılandırmada belgeleyin. Yeni bir olay açıklaması ortaya çıktığında anlamı belirsizse inceleme kuyruğuna alın. Açıkça belirtilmiş bir bilinmeyen durumu, yanlış teslimat sonucunu güvenle atamaktan daha güvenlidir.

Olay zamanını alma zamanından ayırın

Bir olayın gerçekleştiği zamanı, sisteminizin olayı aldığı zamandan ayrı saklayın. Özellikle güncellemeler geciktiğinde veya geçmiş olaylar birlikte sağlandığında eski bir tarama daha yeni bir taramadan sonra ulaşabilir.

Avustralya ve Yeni Zelanda için her gönderiye tek bir sabit saat farkı uygulamaktan kaçının. Sağlandığında kaynak zaman damgalarını ve farklarını koruyun. Güvenilir konum bağlamına sahip olduğunuzda görüntüleme için uygun adlandırılmış bir saat dilimi kullanın ve yaz saati uygulaması farklılıklarını hesaba katın. Kaynak saat dilimi eksikse kesin bir UTC dönüşümü uydurmak yerine bu belirsizliği koruyun.

Güvenilir bir veri alma iş akışı uygulayın

1. Önce dahili gönderiyi oluşturun. Takip hizmetine kaydetmeden önce sipariş ilişkisini, rotayı, taşıyıcı seçimini ve takip kimliğini kaydedin.
2. Takip kaydını gönderin. Sağlayıcının belgelenmiş istek biçimini kullanın. Yanıtı saklayın ve başarılı kaydı, taşıyıcı olaylarının daha sonra kullanılabilir hale gelmesinden ayırın.
3. Hataları sınıflandırın. Geçersiz giriş ve kimlik doğrulama sorunlarını geçici hizmet arızalarından ayırın. Yalnızca yeniden denemenin makul ölçüde yardımcı olabileceği durumlarda yeniden deneyin.
4. Güncellemeleri alın veya getirin. Seçtiğiniz API'nin desteklediği teslim mekanizmasını uygulayın. Webhook kullanıyorsanız gelen istekleri sağlayıcının belgelenmiş yöntemiyle doğrulayın ve kabul edilen olayları kalıcı bir kuyruk üzerinden işleyin.
5. Değişiklikleri uygulamadan önce yinelenenleri kaldırın. Varsa sağlayıcı olay kimliğini veya dikkatle tasarlanmış bileşik bir anahtarı kullanın. Yinelenen teslimatlar yinelenen müşteri bildirimlerini tetiklememelidir.
6. Gönderi durumunu yeniden hesaplayın. Mevcut durumu son gelen güncellemeyle değiştirmek yerine olayın anlamını ve kronolojisini değerlendirin.
7. Eksik kayıtları uzlaştırın. API destekliyorsa kaçırılan güncellemeleri veya kullanım sınırları dahilindeki eski kayıtları incelemek için veri getirme özelliğini kullanın.

Sağlayıcıya özgü kimlik doğrulamayı, alan adlarını ve hata işlemeyi bir adaptör içinde tutun. Sipariş yönetim sisteminiz doğrudan her sağlayıcı yanıtının ayrıntılarına bağlı olmak yerine dahili gönderi modelinizi kullanmalıdır. Bu ayrım, sonraki API değişikliklerinin test edilmesini de kolaylaştırır.

Tasman Denizi ötesi yolculukları kesinlik uydurmadan yönetin

Sınır ötesi takip, durum etiketleri dizisinden daha fazla bağlam gerektirir. Kaynak veriler bu ayrımları desteklediğinde uygulamanız ihracat olayını, gümrükle ilgili olayı, taşıyıcı devrini ve son teslimat olayını birbirinden ayırmalıdır.

Genel bir taşıma taramasından gümrük işlemlerinin tamamlandığı sonucunu çıkarmayın. Benzer şekilde, yakın zamanda tarama yapılmamış olması gümrüğün paketi tuttuğunu göstermez. Yararlı bir müşteri mesajı son doğrulanmış olayı ve zamanını belirtir, ardından ekibinizin gerçekten destekleyebileceği sonraki eylemi açıklar.

Çıkış ve varış noktalarını tarama konumundan ayrı tutun. Avustralya'dan Yeni Zelanda'ya giden bir gönderi, yalnızca varış taraması aldığı için Yeni Zelanda içi bir gönderiye dönüşmez. Bu ayrım rota raporlaması ve istisna sorumluluğu açısından önemlidir.

Bir teslimat ortağı sürece dahil olursa takip kaydını yalnızca gönderi verileri, takip hizmeti veya operasyonel olarak doğrulanmış bir kayıt bu ilişkiyi desteklediğinde bağlayın. Kimlikler benzer görünüyor diye paketleri birleştirmeyin.

Takip olaylarını yararlı müşteri güncellemelerine dönüştürün

Müşteriye yönelik sayfanız dört soruyu yanıtlamalıdır: son doğrulanmış durum nedir, ne zaman gerçekleşti, biliniyorsa nerede kaydedildi ve müşterinin eyleme geçmesi gerekiyor mu?

Bildirim kurallarını olay alımından ayrı tutun. Her tarama e-posta veya kısa mesajı hak etmez. İlk doğrulanmış hareket, teslimat girişimi, teslim alma gerekliliği veya teslim edildi olayı gibi anlamlı geçişleri tanımlayın ve aynı geçiş için yinelenen uyarıları bastırın.

• Eski takip: Sessizliği kayıp kanıtı olarak değerlendirmeden son güncellemenin ne zaman gerçekleştiğini belirtin.
• Teslimat tahminleri: Taşıyıcı tarafından sağlanan tahmini, satıcının vaadinden ayırın. Hiçbiri yoksa tarih üretmeyin.
• İstisnalar: Açıklanamayan bir hata etiketi göstermek yerine biliniyorsa somut bir sonraki adımı verin.
• Teslimat anlaşmazlıkları: Kaynak olayı koruyun ve durumu destek ekibine yönlendirin; yalnızca teslim edildi durumu her müşteri anlaşmazlığını çözmez.

Takip sayfalarını da API kimlik bilgileri kadar koruyun. Gereksiz adres veya iletişim bilgilerini açığa çıkarmaktan kaçının, hizmet kimlik bilgilerini sunucuda tutun ve görüntülenen bilgilere uygun erişim kontrolleri uygulayın.

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

İşletmeniz açısından ilgili olduğunda Avustralya içi, Yeni Zelanda içi, Avustralya'dan Yeni Zelanda'ya ve Yeni Zelanda'dan Avustralya'ya gönderileri test edin. Olağan teslimatların yanı sıra bölünmüş siparişler, tanınmayan numaralar, devir teslimler, teslimat girişimleri, teslim alma olayları, iadeler ve geç gelen taramalar gibi operasyonel uç durumları da dahil edin.

Taşıyıcı doğrulaması için uygun izinlere sahip gerçek gönderi kayıtlarını kullanın. Kendi uygulamanızın dayanıklılığını test etmek için sentetik olaylar kullanabilirsiniz; ancak sentetik sonuçları canlı taşıyıcı kapsamının kanıtı olarak değerlendirmeyin.

• Kimlik kontrolü: Her güncelleme doğru gönderiye ve siparişe ulaşıyor.
• Kronoloji kontrolü: Sırası dışında gelen olaylar teslimat ilerlemesini yanlış biçimde geri çevirmiyor.
• Kurtarma kontrolü: Geçici arızalar ve yinelenen güncellemeler veri kaybına veya yinelenen uyarılara neden olmuyor.
• Destek kontrolü: Temsilciler özgün olayı inceleyebiliyor ve müşteriye gösterilen durumu anlayabiliyor.
• Ticari kontrol: Beklenen kullanım, hesabın doğrulanmış faturalandırma modeli ve sınırlarına uyuyor.

Pilotu değerlendirmeden önce kabul eşiklerini belirleyin. Kayıt sonuçlarını, eşlenmemiş olayları, işleme gecikmelerini, yinelenen bildirimleri ve çözümlenmemiş eski gönderileri ölçün. Düzeltmenin doğru sorumluya ulaşması için taşıyıcı verilerindeki gecikmeleri kendi uygulamanızdaki gecikmelerden ayırın.

Uygulama, ekibiniz eksik takibi yalnızca başarılı teslimatları göstermekle kalmadan açıklayıp kurtarabildiğinde hazırdır. Tek bir API bağlantıyı basitleştirir; gönderi modeliniz, olay kurallarınız ve operasyon prosedürleriniz bu bağlantıyı güvenilir hale getirir.

SSS

Tek bir takip API'si taşıyıcı gönderi entegrasyonlarının yerini alır mı?

Şart değil. Takip, etiket oluşturma, teslim alma rezervasyonu, ücret hesaplama ve gümrük belgeleri ayrı işlevlerdir. Seçilen ürünün kapsamını doğrulayın ve sipariş karşılama sürecinizin gerektirdiği diğer entegrasyonları koruyun.

İlk taşıyıcı taramasından önce bir takip numarası kaydedebilir miyim?

API'nin kayıt kurallarını kontrol edin. Uygulamanızı, kabul edilmiş bir takip kaydını doğrulanmış fiziksel hareketten ayıracak şekilde tasarlayın. Olay içermeyen bir kayıt otomatik olarak taşımada olarak gösterilmemelidir.

Tek bir API her taşıyıcı için gerçek zamanlı güncellemeler sağlar mı?

Bunu varsaymayın. Uçtan uca güncellik, taşıyıcının verileri ne zaman yayımladığına, takip hizmetinin bunları ne zaman aldığına ve uygulamanızın ne zaman işlediğine bağlıdır. Kullandığınız taşıyıcı-hizmet kombinasyonları için güncelleme davranışını doğrulayın.

Takip numarası değiştiğinde ne olmalı?

Özgün kimliği koruyun ve doğrulanmış değiştirme veya iş ortağı kimliğini aynı dahili gönderiye ekleyin. Her iki geçmişi de koruyun ve yinelenen kayıtların çakışan bildirimler oluşturmasını önleyin.

17TRACK bu entegrasyonla ilgili mi?

Evet. Tracking API'si burada açıklanan çoklu taşıyıcı entegrasyonuyla ilgilidir. Avustralya ve Yeni Zelanda gönderi örneklerinizi kullanarak değerlendirin ve dağıtımdan önce resmî API kaynakları üzerinden taşıyıcı desteğini, teknik davranışı ve hesap şartlarını doğrulayın.

Kaynaklar

• 17TRACK Tracking API — bu kılavuzda ele alınan API seçeneği için resmî ürün kaynağı.
• 17TRACK API belgeleri — istek biçimlerini, entegrasyon gereksinimlerini ve desteklenen davranışları kontrol etmek için resmî teknik referans.