Tracking API və Shipping API: E-ticarət stack-iniz hansına ehtiyac duyur (yaxud hər ikisinə)?

E-ticarət stekiniz göndərişlər yaratmalı və göndəriş etiketləri hazırlamalıdırsa, shipping API-dən istifadə edin. Göndərişdən sonra göndərişləri izləməli və daşıyıcı yeniləmələrini faydalı əməliyyat və ya müştəriyə yönəlik məlumatlara çevirməlidirsə, tracking API-dən istifadə edin. Proqram təminatınız göndərişlərin yaradılmasını və alışdan sonrakı görünürlüğü idarə etməlidirsə, hər iki imkan sizə lazımdır, lakin mütləq iki provayderə və ya iki ayrı inteqrasiyaya ehtiyacınız yoxdur.

Qərarı icra arxitekturanıza cavabdeh olan şəxs verməlidir: adətən mühəndislik komandası ilə işləyən e-ticarət əməliyyatları rəhbəri. Mağazanızın, anbarınızın və ya icra tərəfdaşınızın artıq nələri idarə etdiyini müəyyən etməklə başlayın. Başqa API əlavə etmək artıq işləyən iş axınını təkrarlamamalı, konkret boşluğu aradan qaldırmalıdır.

Tracking API ilə shipping API arasındakı fərq nədir?

Fərq əsasən hər bir API-nin yerinə yetirdiyi vəzifə ilə bağlıdır, məhsul kateqoriyaları arasında sərt sərhədlə deyil. Göndəriş platformasına izləmə endpoint-ləri daxil ola bilər, izləmə xidməti isə bildirişlər və müştəriyə yönəlik çatdırılma yeniləmələri üçün alətlər təqdim edə bilər. Məhsul adına əsaslanmaq əvəzinə sənədləşdirilmiş endpoint-ləri və hadisə davranışını qiymətləndirin.

Qərar meyarı	Tracking API	Shipping API
Əsas vəzifə	Göndəriş statusunu və izləmə hadisələrini əldə etmək və ya qəbul etmək.	Göndərişlər yaratmaq və etiketləri, eləcə də əlaqəli göndəriş sənədlərini əldə etmək.
Tipik girişlər	İzləmə nömrəsi, daşıyıcı identifikatoru və tələb olunan digər göndəriş məlumatları.	Göndərən və alıcı məlumatları, bağlama məlumatları, xidmət seçimi və tətbiq olunan gömrük məlumatları.
Tipik çıxışlar	Göndəriş statusu, hadisə tarixçəsi və mövcud digər çatdırılma məlumatları.	Göndəriş identifikatorları, etiketlər və dəstəklənən sənədlər.
Əsas iş axını	Çatdırılma görünürlüğü, istisnaların idarə edilməsi və alışdan sonrakı yeniləmələr.	Anbardan göndərilmə və çıxış göndərişinin hazırlanması.
Nəyi fərz etməməli	İzləmə imkanının etiket yaradılmasını və ya daşıyıcı sifarişini əhatə etdiyini.	Etiket yaradılmasının sizə lazım olan izləmə dərinliyini və bildiriş nəzarətlərini əhatə etdiyini.

Daşıyıcı sənədləri bu ayrılığı nümayiş etdirir. FedEx göndəriş yaratma prosesini Ship API documentation bölməsində, izləmə imkanlarını isə tracking API documentation bölməsində sənədləşdirir. Bunlar müəyyən bir daşıyıcını seçmək tövsiyəsi deyil, fərqli texniki məsuliyyətlərə nümunələrdir.

Göndəriş yaratmaq onun hərəkətini müşahidə etməklə eyni deyil

Uğurlu göndəriş yaratma cavabı proqram təminatınıza göndəriş sorğusunun emal edildiyini bildirir. Bu, daşıyıcının bağlamanı fiziki olaraq qəbul etdiyini təsdiqləmir. Eyni şəkildə, izləmə tarixçəsində hərəkət görünməzdən əvvəl də izləmə nömrəsi mövcud ola bilər.

Buna görə sifariş idarəetmə sisteminiz etiket yaradılmasını, anbardan təhvil verilməni, daşıyıcının qəbulunu və çatdırılmanı fərqləndirməlidir. Bunların hamısına vahid “göndərildi” hadisəsi kimi yanaşmaq müştərilərə vaxtından əvvəl göndərilən mesajlara və anbardan faktiki çıxmamış bağlamaların gözdən yayınmasına səbəb ola bilər.

Mövcud darboğazınızı aradan qaldıran imkanı seçin

Göndərilmə çatışmayan hissədirsə, shipping API seçin

Öz tətbiqiniz sifariş məlumatlarını göndərişə çevirməlidirsə, shipping API uyğun başlanğıc nöqtəsidir. Buna nümunə olaraq anbar komandasının ünvanları daşıyıcı portallarına əl ilə köçürməsi və ya etiket yarada bilməyən xüsusi sifariş idarəetmə sistemi göstərilə bilər.

İnteqrasiya seçməzdən əvvəl faktiki göndərilmə iş axınını müəyyən edin. Sizə yalnız göndəriş yaratmaq lazımdır, yoxsa tariflərin əldə edilməsi, ləğv etmə, götürmə sorğuları, gömrük sənədləri və ya gün sonu prosesləri də lazımdır? Bu funksiyalar ayrı API-lər ola, daşıyıcıdan asılı ola və ya əlavə hesab icazələri tələb edə bilər. “shipping API” adlanan məhsulun bütün göndəriş əməliyyatlarını əhatə etdiyini fərz etməyin.

Yeganə həll kimi ideal deyil: müştəri xidmətləri komandanızı ayrı-ayrı daşıyıcı veb-saytlarını yoxlamağa məcbur edən etiket yaratma inteqrasiyası. Bu, göndərilmə problemini həll edə bilər, lakin çatdırılma görünürlüğünü böyük ölçüdə dəyişməz saxlaya bilər.

Göndəriş yaratma artıq işləyirsə, tracking API seçin

Etiketlər artıq anbar idarəetmə sisteminiz, icra tərəfdaşınız, marketplace və ya mövcud göndəriş inteqrasiyanız tərəfindən yaradılırsa, lakin çatdırılma məlumatları parçalanmış vəziyyətdədirsə, tracking API daha birbaşa uyğun seçimdir.

Bu vəziyyətdə etiket iş axınını dəyişdirmək əsas problemi həll etmədən miqrasiya işini artıra bilər. Bunun əvəzinə yuxarı axında yaradılan izləmə nömrələrini sifariş idarəetmə sisteminizin, dəstək alətlərinizin və müştəri kommunikasiyalarınızın istifadə edə biləcəyi görünürlük qatına qoşun.

Bu kateqoriya üçün 17TRACK Tracking API uyğun inteqrasiya seçimidir. Onun official API documentation sənədlərində izləmə nömrəsinin qeydiyyatı və izləmə məlumatı iş axınları, o cümlədən push bildirişləri təsvir olunur. Bu iş axınlarını tələb etdiyiniz daşıyıcılar, göndəriş növləri və tətbiq arxitekturanızla müqayisə edin. Bu, izləmə qatı ilə bağlı məsələdir və xidmətin etiket yaratma inteqrasiyasını əvəz etdiyinə sübut deyil.

Yeganə həll kimi ideal deyil: proqram təminatınızın göndərilməsinə cavabdeh olduğu göndərişləri yaratmaq üçün hələ də heç bir imkanı olmadığı halda tracking API-dən istifadə etmək. İzləmə görünürlüğü çatışmayan göndəriş icrasını həll etmir.

Tətbiqiniz həm göndərilməyə, həm də çatdırılma görünürlüğünə cavabdehdirsə, hər ikisindən istifadə edin

Stekiniz etiketlər yaratmalı və sonra göndərişin irəliləyişi barədə etibarlı görünüşü saxlamalıdırsa, hər iki imkan uyğundur. Bunlar bir platformadan, ayrı xidmətlərdən və ya daşıyıcı inteqrasiyaları ilə izləmə qatının birləşməsindən əldə edilə bilər.

Göndəriş və izləmə funksiyaları sənədləşdirilmiş tələblərinizi lazımsız güzəştlər olmadan qarşılayırsa, bir inteqrasiyaya üstünlük verin. Mövcud göndəriş iş axınını qorumaq vacibdirsə və ya izləmə tələbləri həmin iş axınının təmin etdiklərindən əhəmiyyətli dərəcədə fərqlənirsə, ayrı inteqrasiyaları nəzərdən keçirin. Ayrı izləmə provayderi avtomatik olaraq daha yaxşı deyil; o, əlavə inteqrasiya, ödəniş və əməliyyat məsuliyyətini əsaslandırmalıdır.

Hər iki API e-ticarət stekinə necə inteqrasiya olunur

Praktik dizayn sifariş, göndəriş və izləmə hadisəsini ayrı qeydlər kimi saxlayır. Bir sifariş bir neçə bağlama yarada bilər və hər bağlamanın öz izləmə tarixçəsi ola bilər. Müştəriyə göstərilən sifariş statusu həmin qeydlərin üzərinə yazılmaq əvəzinə göndəriş qeydlərindən formalaşdırılmalıdır.

1. Sifariş icraya hazır olur. Mağaza və ya sifariş idarəetmə sistemi tələb olunan icra məlumatlarını məsul anbara göndərir.
2. Göndəriş iş axını göndərişi yaradır. Tətbiq qaytarılan göndəriş identifikatorunu, izləmə nömrəsini, daşıyıcını, xidməti və etiket istinadını saxlayır.
3. Anbar təhvil verməni tamamlayır. Anbar təsdiqi və daşıyıcının qəbulu fərqləndirilə bilən hadisələr olaraq qalır.
4. İzləmə iş axını başlayır. Tətbiqiniz seçilmiş inteqrasiyanın tələb etdiyi qaydada izləmə nömrəsini qeydiyyatdan keçirir və ya təqdim edir.
5. İzləmə yeniləmələri tətbiqinizə çatır. Webhook-lar, sorğulama və ya dəstəklənən kombinasiya göndəriş qeydini yeniləyir.
6. Biznes qaydaları növbəti addımı müəyyən edir. Müvafiq şərtlər ödənildikdə sisteminiz müştəriyə göstərilən statusu yeniləyir, əməliyyat tapşırığı yaradır və ya mesaj göndərir.

Məsələn, üçüncü tərəf icra anbarından istifadə edən tacirə öz proqram təminatında yalnız dördüncü-altıncı addımlar lazım ola bilər. Göndəriş yaratma artıq anbarın məsuliyyətindədir. Öz anbarını idarə edən tacirə isə tam iş axını lazım ola bilər.

Hər bir sonrakı əməliyyat üçün bir məsul təyin edin

Hər iki inteqrasiya izləmə yeniləmələri təqdim edirsə, müştəri bildirişlərinə və mağazanızda göstərilən göndəriş statusuna hansı sistemin nəzarət etdiyini müəyyən edin. Əks halda müştərilər təkrar mesajlar ala və ya bir-birinə zidd çatdırılma statusları görə bilər.

Araşdırma üçün ikinci dərəcəli məlumatları saxlaya bilərsiniz, lakin hər mənbənin e-poçt göndərməsinə icazə verməyin. Daxili status xəritələndirmənizlə yanaşı orijinal daşıyıcı hadisəsini qoruyun ki, dəstək əməkdaşları sistemin göndərişi niyə müəyyən şəkildə təsnif etdiyini anlaya bilsinlər.

Funksiya etiketlərini deyil, əməliyyat uyğunluğunu müqayisə edin

Faktiki istifadə etdiyiniz daşıyıcıları və xidmətləri yoxlayın

Daşıyıcı dəstəyi sadə “bəli” və ya “xeyr” sualı deyil. Xidmət bir daşıyıcı üçün izləməni dəstəkləyə, lakin həmin daşıyıcı üçün etiket yaradılmasını dəstəkləməyə bilər. Etiket yaradılması həmçinin mənşə ölkəsindən, daşıyıcı hesabının qurulmasından və ya xidmət uyğunluğundan asılı ola bilər.

Faktiki göndəriş marşrutlarınız əsasında test siyahısı hazırlayın. Daxili bağlamaları, beynəlxalq göndərişləri və nəqliyyat tərəfdaşları arasındakı hər hansı təhvil-təslimi daxil edin. Hər biri üçün tələb olunan əməliyyatı — göndəriş yaratmaq, izləmək və ya hər ikisini — təsdiqləyin. Geniş əhatə bəyanatı biznesinizin asılı olduğu xidmətlərin uğurlu testlərindən daha az faydalıdır.

Hadisə mənasını və məlumatların tamlığını yoxlayın

İzləmə üçün ilk skandan əvvəl, çatdırılma istisnası zamanı, uğursuz çatdırılma cəhdindən sonra və çatdırılma anında nə baş verdiyini test edin. Vaxt möhürlərinin saat qurşağı məlumatlarını ehtiva edib-etmədiyini və orijinal daşıyıcı təsvirlərinin əlçatan olaraq qalıb-qalmadığını yoxlayın.

Normallaşdırılmış statusu hər daşıyıcı üzrə məlumatların eyni olacağına dair vəd kimi şərh etməyin. Təxmini çatdırılma tarixləri, məkan məlumatları və çatdırılma sübutu əsas daşıyıcıdan və göndərişdən asılı ola bilər. Bu sahələr olmadıqda interfeysinizin necə davranacağını müəyyən edin.

Hər iki tərəfdə uğursuzluqlardan bərpanı yoxlayın

Göndəriş zamanı göndəriş yaradılmasının ortasında baş verən vaxt aşımı xüsusi diqqət tələb edir: tətbiqiniz cavabı almasa belə, sorğu uğurlu olmuş ola bilər. Kor-koranə yenidən cəhd etməzdən əvvəl provayderin dəstəklədiyi dublikatların qarşısının alınması və uzlaşdırma mexanizmlərini yoxlayın.

İzləmə üçün dublikat bildirişləri, gecikmiş hadisələri, uğursuz webhook çatdırılmasını və endpoint-lərin müvəqqəti əlçatmazlığını test edin. Müvafiq sənədlərdə autentifikasiyanı, yenidən cəhd davranışını və bərpa seçimlərini təsdiqləyin. Hadisələrin emalını elə dizayn edin ki, yeniləmənin təkrar oynadılması eyni müştəri bildirişini yenidən göndərməsin.

Qiymət modelini fərz etmədən ümumi əməliyyat xərclərini müqayisə edin

API ödənişlərini poçt və daşıyıcı hesabı ödənişlərindən ayırın. Göndəriş və izləmə xidmətləri fərqli hesablaşma vahidlərindən istifadə edə bilər, birləşdirilmiş platforma isə imkanları fərqli şəkildə paketləyə bilər. İcra etmək istədiyiniz dəqiq iş axını üçün qiymət təklifi alın və ya müvafiq planı nəzərdən keçirin.

Hesablanan istifadənin necə müəyyən edildiyini, uğursuz sorğuların nəzərə alınıb-alınmadığını, təkrar izləmə təqdimlərinin necə idarə edildiyini və istifadə limiti aşıldıqda nə baş verdiyini soruşun. Mühəndislik dəstəyini, dəstək səylərini və iki inteqrasiyanın ardıcıl saxlanması xərclərini də daxil edin. Müəyyən edilmiş göndəriş qarışığı və mövcud kommersiya şərtləri olmadan bir kateqoriyanın daha ucuz olduğunu elan etmək yanıltıcı olardı.

Təhlükəsizliyi və məlumatların saxlanılmasını nəzərdən keçirin

Göndəriş inteqrasiyaları alıcı ünvanlarını və gömrük məlumatlarını emal edə bilər. İzləmə inteqrasiyaları həmçinin göndəriş identifikatorlarını və əlaqəli müştəri məlumatlarını emal edə bilər. Hansı sahələrin tələb olunduğunu təsdiqləyin, giriş məlumatlarını zəruri icazələrlə məhdudlaşdırın və məxfi məlumatları brauzer tərəfi kodundan kənarda saxlayın.

Saxlanma, silinmə və giriş nəzarətlərini biznes tələblərinizə uyğun nəzərdən keçirin. Rahat inteqrasiya iş axınının ehtiyac duymadığı müştəri məlumatlarının göndərilməsini tələb etməməlidir.

Qərar verməzdən əvvəl praktiki yoxlama planı

Sürətli başlanğıc təlimatındakı yalnız uğurlu nümunədən istifadə etmək əvəzinə, real göndərişləri təmsil edən nümunələrlə konsepsiya sübutu həyata keçirin. Əməliyyat, mühəndislik və müştəri dəstəyi komandaları ilə qəbul meyarlarını razılaşdırın.

• Göndərilmə: tələb olunan etiket formatlarını yaradın və anbar avadanlığının onlardan istifadə edə bildiyini təsdiqləyin.
• Sifariş xəritələndirməsi: orijinal tarixçəni itirmədən bölünmüş göndərişləri, bir neçə bağlamanı və əvəzedici göndərişləri test edin.
• İzləmə: biznesiniz üçün əhəmiyyətli daşıyıcılar və marşrutlar üzrə real hadisə ardıcıllıqlarını yoxlayın.
• İstisnalar: icra edilə bilən çatdırılma probleminin hər qeyri-adi skanı avtomatik olaraq uğursuzluq kimi qiymətləndirmədən düzgün komandaya çatdığını təsdiqləyin.
• Bərpa: sorğunu və ya webhook endpoint-ini dayandırın və tətbiqin çatışmayan məlumatları necə uzlaşdırdığını nümayiş etdirin.
• Kommunikasiya: hər bir müştəri bildirişini yalnız təyin edilmiş sistemin göndərdiyini təsdiqləyin.
• Kommersiya uyğunluğu: gözlənilən istifadəniz və provayderin təsdiqlənmiş hesablaşma tərifləri əsasında ödənişləri təxmin edin.

Qərar qaydası: əvvəlcə çatışmayan imkanı əldə edin. Göndərilmə artıq işləyirsə, icranı yenidən qurmadan izləmə inteqrasiyasını qiymətləndirin. Etiket yaradılması çatışmırsa, əvvəlcə göndəriş icrasını həll edin. Tətbiqiniz bütün göndəriş həyat dövrünə sahibdirsə, hər iki imkanı yoxlayın və birləşdirilmiş, yoxsa ayrı arxitekturanın komandanız üçün idarə edilməsinin daha asan olduğuna qərar verin.

FAQ

Shipping API həmişə izləməni əhatə edir?

Xeyr. Bəzi xidmətlər hər iki imkanı ehtiva edir, digərləri isə onları ayrı endpoint-lər, məhsullar və ya planlar vasitəsilə təqdim edir. İzləmə daxil edilsə belə, onu alışdan sonrakı izləmə həlliniz hesab etməzdən əvvəl hadisə təfərrüatlarını, yeniləmələrin çatdırılma üsulunu, daşıyıcı dəstəyini və istifadə şərtlərini yoxlayın.

Etiketləri icra tərəfdaşı tərəfindən yaradılmış bağlamaları izləyə bilərəm?

Potensial olaraq, bəli. Tətbiqinizə izləmə inteqrasiyasının tələb etdiyi identifikatorlar, adətən izləmə nömrəsi və tələb olunduqda daşıyıcı identifikatoru və ya əlavə yoxlama məlumatları lazımdır. Tərəfdaşın daşıyıcılarına dəstəyi təsdiqləyin və izləmə nömrələrinin sisteminizə etibarlı şəkildə ötürüldüyünə əmin olun.

Tracking API daşıyıcı skanlarının daha tez baş verməsini təmin edəcək?

O, fiziki daşıyıcı skanları yarada bilməz. Tətbiqinizə izləmə mənbələri vasitəsilə təqdim edilən məlumatları əldə etməyə, təşkil etməyə və yaymağa kömək edə bilər. API-nin hərəkət barədə dərhal görünürlüğə zəmanət verdiyini fərz etmək əvəzinə, yeniləmə davranışını real göndərişlərlə qiymətləndirin.

Hər iki imkandan istifadə etmək üçün iki API provayderinə ehtiyacım var?

Xeyr. Sizə iki satıcı deyil, hər iki funksiya lazımdır. Tələblərinizi qarşılayırsa, bir provayderdən istifadə edin. İşlək iş axınını qoruyursa və ya birləşdirilmiş seçimin təmin etmədiyi konkret tələbi qarşılayırsa, onları ayırın.

Tracking API sifariş idarəetmə sistemini əvəz edə bilər?

Xeyr. İzləmə məlumatları sifariş idarəetməsinə daxil olan məlumatdır, inventarın bölüşdürülməsini, icra qərarlarını, ödənişlərin idarə edilməsini və ya sifariş qeydlərini əvəz etmir. Tətbiqiniz hələ də hər göndərişi düzgün sifarişlə əlaqələndirməli və göndəriş hadisələrinin biznes iş axınlarına necə təsir etdiyini müəyyən etməlidir.

Mənbələr

• FedEx Ship API documentation — göndəriş yaratma, etiketlər və göndəriş iş axını tələbləri üzrə istinad.
• FedEx tracking API documentation — izləmə sorğuları və göndəriş statusu məlumatları üzrə istinad.
• 17TRACK Tracking API — izləmə inteqrasiyası kateqoriyası üzrə rəsmi məhsul istinadı.
• 17TRACK API documentation — izləmənin qeydiyyatı, izləmə məlumatları və push bildiriş inteqrasiyası üzrə istinad.