Πώς να ενοποιήσετε την παρακολούθηση αποστολών σε όλη την Αυστραλία και τη Νέα Ζηλανδία με ένα API

Για να ενοποιήσετε την παρακολούθηση αποστολών σε όλη την Αυστραλία και τη Νέα Ζηλανδία μέσω ενός API, συνδέστε το σύστημα παραγγελιών ή εκπλήρωσης παραγγελιών με μια υπηρεσία παρακολούθησης πολλαπλών μεταφορέων, καταχωρίστε κάθε αποστολή με τη σωστή ταυτότητα μεταφορέα και μεταφράστε τις εισερχόμενες ενημερώσεις παρακολούθησης σε ένα συνεπές εσωτερικό μοντέλο συμβάντων. Η ενοποίηση θα πρέπει να διατηρεί τις λεπτομέρειες που αφορούν κάθε μεταφορέα, παρέχοντας παράλληλα στην ομάδα λειτουργιών και στους πελάτες σας μία ενιαία εμπειρία παρακολούθησης για εγχώριες και δια-Τασμανικές παραδόσεις.

Για προγραμματιστές, διαχειριστές ηλεκτρονικού εμπορίου και ομάδες logistics, η κύρια πρόκληση δεν είναι η πραγματοποίηση του πρώτου αιτήματος API. Είναι η διατήρηση συνεπών ταυτοτήτων αποστολών, καταστάσεων παράδοσης, παραδόσεων μεταξύ μεταφορέων και ειδοποιήσεων πελατών, όταν διαφορετικοί μεταφορείς περιγράφουν το ίδιο ταξίδι με διαφορετικό τρόπο. Αυτός ο οδηγός εξηγεί πώς να σχεδιάσετε αυτή την ενοποίηση, να αξιολογήσετε ένα API παρακολούθησης και να το δοκιμάσετε πριν βασιστείτε σε αυτό σε περιβάλλον παραγωγής.

Καθορίστε τι πρέπει να ενοποιεί το ενιαίο API

Ένα κοινόχρηστο API παρέχει στην εφαρμογή σας ένα κοινό σημείο ενοποίησης. Δεν σημαίνει ότι κάθε μεταφορέας δημοσιεύει πανομοιότυπες πληροφορίες ή σαρώνει τα δέματα με την ίδια συχνότητα. Η αρχιτεκτονική σας πρέπει να διακρίνει μεταξύ μιας συνεπούς διεπαφής και της πλήρους ορατότητας.

Ξεκινήστε με έναν κατάλογο αποστολών που βασίζεται στην πραγματική δραστηριότητα εκπλήρωσης παραγγελιών και όχι σε έναν γενικό κατάλογο μεταφορέων που δραστηριοποιούνται σε οποιαδήποτε από τις δύο χώρες. Συμπεριλάβετε εγχώριες αποστολές στην Αυστραλία, εγχώριες αποστολές στη Νέα Ζηλανδία και διασυνοριακές μετακινήσεις και προς τις δύο κατευθύνσεις. Προσθέστε άλλες χώρες προέλευσης, εφόσον αποτελούν μέρος της επιχειρηματικής σας δραστηριότητας.

• Μεταφορέας και υπηρεσία: Καταγράψτε τον μεταφορέα, την υπηρεσία που χρησιμοποιήθηκε και τυχόν γνωστό συνεργάτη παράδοσης.
• Διαδρομή: Διακρίνετε την προέλευση και τον προορισμό της αποστολής από την τοποθεσία της πιο πρόσφατης σάρωσής της.
• Αναγνωριστικά: Καταγράψτε την αναφορά παραγγελίας, την αναφορά εκπλήρωσης, τον αριθμό παρακολούθησης και τυχόν αριθμό αντικατάστασης ή συνεργάτη.
• Λειτουργικός σκοπός: Καθορίστε αν οι ενημερώσεις υποστηρίζουν την παρακολούθηση από τον πελάτη, τη διαχείριση εξαιρέσεων, την επιβεβαίωση παράδοσης ή και τα τρία.
• Απαιτούμενη λεπτομέρεια: Αποφασίστε αν αρκεί μια γενική κατάσταση παράδοσης ή αν οι υπάλληλοι χρειάζονται επίσης περιγραφές σαρώσεων, τοποθεσίες και χρονικές σημάνσεις.

Αυτός ο κατάλογος αποτελεί τη λίστα ελέγχου αποδοχής σας. Η γενική κάλυψη μεταφορέων ενός παρόχου είναι χρήσιμη για την αρχική επιλογή, όμως η απόφασή σας θα πρέπει να βασίζεται στο αν οι πραγματικοί συνδυασμοί μεταφορέων και υπηρεσιών σας επιστρέφουν αξιοποιήσιμες πληροφορίες παρακολούθησης.

Αξιολογήστε το API παρακολούθησης με βάση το μείγμα αποστολών σας

Το 17TRACK προσφέρει ένα Tracking API, γεγονός που το καθιστά σχετική επιλογή για αξιολόγηση σε μια ενοποίηση πολλαπλών μεταφορέων. Χρησιμοποιήστε την επίσημη τεκμηρίωση API για να ελέγξετε τις τρέχουσες απαιτήσεις ενοποίησης. Αντιμετωπίστε την υποστήριξη μεταφορέων, τα πεδία συμβάντων, τη συμπεριφορά ενημερώσεων, τα όρια λογαριασμού και τους εμπορικούς όρους ως στοιχεία που πρέπει να επαληθεύσετε για την υλοποίησή σας και όχι ως υποθέσεις που προκύπτουν από την κατηγορία του προϊόντος.

Υποβάλετε τα ίδια πρακτικά ερωτήματα για κάθε API που εξετάζετε:

• Μπορεί να αναγνωρίσει και να παρακολουθήσει τους μεταφορείς και τις υπηρεσίες του καταλόγου αποστολών σας;
• Όταν η ανίχνευση μεταφορέα είναι αμφίβολη, μπορείτε να παρέχετε ένα ρητό αναγνωριστικό μεταφορέα;
• Πώς λαμβάνει ενημερώσεις η εφαρμογή σας και ποιος μηχανισμός ανάκτησης είναι διαθέσιμος αν χαθεί μια ενημέρωση;
• Ποιες λεπτομέρειες του αρχικού μεταφορέα παραμένουν διαθέσιμες παράλληλα με τις κανονικοποιημένες καταστάσεις;
• Τι συμβαίνει όταν ένας αριθμός παρακολούθησης είναι μη έγκυρος, δεν έχει ακόμη αναγνωριστεί ή συνδέεται με περισσότερους από έναν πιθανούς μεταφορείς;
• Πώς καθορίζονται για τον λογαριασμό σας η χρήση, η χρέωση, η διάρκεια παρακολούθησης και τα όρια πρόσβασης;

Προτεινόμενος κανόνας απόφασης: επιλέξτε με βάση επιτυχείς δοκιμές των πραγματικών μοτίβων αποστολής σας και όχι τον μεγαλύτερο συνολικό αριθμό μεταφορέων που αναφέρεται. Μια ενοποίηση είναι κατάλληλη όταν παρέχει αρκετές πληροφορίες για την υποστήριξη των λειτουργικών σας αποφάσεων και εμφανίζει τις αποτυχίες με αρκετή σαφήνεια ώστε να μπορείτε να τις αντιμετωπίσετε.

Δημιουργήστε ένα εσωτερικό μοντέλο που αντέχει στις διαφορές μεταξύ μεταφορέων

Διαχωρίστε τις παραγγελίες, τις αποστολές και τα σκέλη παρακολούθησης

Μην χρησιμοποιείτε τον αριθμό παρακολούθησης ως κύριο κλειδί για μια παραγγελία. Μία παραγγελία μπορεί να περιέχει πολλά δέματα και η διαδρομή ενός δέματος μπορεί να περιλαμβάνει περισσότερα από ένα αναγνωριστικά παρακολούθησης. Αντί γι’ αυτό, δημιουργήστε ένα εσωτερικό αναγνωριστικό αποστολής και συνδέστε σε αυτό τις εγγραφές παρακολούθησης.

Ένα πρακτικό μοντέλο έχει τρία επίπεδα: την παραγγελία του πελάτη, τις φυσικές αποστολές της και τα σκέλη παρακολούθησης που συνδέονται με κάθε αποστολή. Ένα εγχώριο δέμα μπορεί να χρειάζεται μόνο ένα σκέλος παρακολούθησης. Ένα διασυνοριακό δέμα μπορεί να απαιτεί συνδεδεμένες εγγραφές όταν ένας άλλος μεταφορέας ή αναγνωριστικό αποκτά σημασία.

Ορίστε μια εγγραφή παρακολούθησης με βάση τόσο τον μεταφορέα όσο και τον αριθμό παρακολούθησης και διατηρήστε τη σχέση της με το αναγνωριστικό αποστολής. Αν εμφανιστεί νέος αριθμός συνεργάτη παράδοσης, προσθέστε τον ως σχετικό αναγνωριστικό αντί να αντικαταστήσετε το αρχικό. Έτσι διατηρείται το ιστορικό που χρειάζονται οι υπάλληλοι υποστήριξης κατά τη διερεύνηση μιας παράδοσης μεταξύ μεταφορέων.

Διατηρήστε ένα πρωτογενές και ένα κανονικοποιημένο συμβάν

Χρησιμοποιήστε ένα μικρό εσωτερικό λεξιλόγιο καταστάσεων βάσει του οποίου μπορεί να ενεργεί η επιχείρησή σας. Για παράδειγμα, μπορείτε να ορίσετε: πριν από τη μεταφορά, σε μεταφορά, προς παράδοση, διαθέσιμο για παραλαβή, παραδόθηκε, εξαίρεση και άγνωστο. Αυτές είναι προτεινόμενες εσωτερικές κατηγορίες και όχι ισχυρισμός σχετικά με το σχήμα καταστάσεων ενός συγκεκριμένου παρόχου.

Αποθηκεύστε την αρχική περιγραφή του μεταφορέα παράλληλα με την αντιστοιχισμένη κατάσταση. Ένα συμβάν σε σημείο παραλαβής και ένα πρόβλημα διεύθυνσης μπορεί να απαιτούν και τα δύο ενέργεια από τον πελάτη, όμως δεν θα πρέπει να δημιουργούν το ίδιο μήνυμα. Ομοίως, η δημιουργία μιας ετικέτας δεν θα πρέπει να μετατρέπεται αυτόματα σε απόδειξη ότι ο μεταφορέας έχει παραλάβει φυσικά το δέμα.

Τεκμηριώστε τις αποφάσεις αντιστοίχισης σε μια έκδοση διαμόρφωσης. Όταν εμφανίζεται μια νέα περιγραφή συμβάντος, τοποθετήστε την σε ουρά ελέγχου αν η σημασία της δεν είναι σαφής. Μια ρητή κατάσταση «άγνωστο» είναι ασφαλέστερη από την εσφαλμένη αλλά βέβαιη ανάθεση αποτελέσματος παράδοσης.

Διακρίνετε τον χρόνο του συμβάντος από τον χρόνο λήψης

Αποθηκεύστε ξεχωριστά πότε συνέβη ένα συμβάν και πότε το έλαβε το σύστημά σας. Μια παλαιότερη σάρωση μπορεί να φτάσει μετά από μια νεότερη, ιδιαίτερα όταν οι ενημερώσεις καθυστερούν ή παρέχονται ταυτόχρονα ιστορικά συμβάντα.

Για την Αυστραλία και τη Νέα Ζηλανδία, αποφύγετε την εφαρμογή μίας σταθερής μετατόπισης ώρας σε κάθε αποστολή. Διατηρήστε τις χρονικές σημάνσεις και τις μετατοπίσεις της πηγής, όταν παρέχονται. Χρησιμοποιήστε κατάλληλη ονομαστική ζώνη ώρας για την εμφάνιση όταν διαθέτετε αξιόπιστο πλαίσιο τοποθεσίας και λάβετε υπόψη τις διαφορές θερινής ώρας. Αν λείπει η ζώνη ώρας της πηγής, διατηρήστε αυτή την αβεβαιότητα αντί να επινοήσετε μια ακριβή μετατροπή UTC.

Υλοποιήστε μια αξιόπιστη ροή λήψης δεδομένων

1. Δημιουργήστε πρώτα την εσωτερική αποστολή. Καταγράψτε τη σχέση της με την παραγγελία, τη διαδρομή, την επιλογή μεταφορέα και το αναγνωριστικό παρακολούθησης πριν από την καταχώριση στην υπηρεσία παρακολούθησης.
2. Υποβάλετε την καταχώριση παρακολούθησης. Χρησιμοποιήστε τη μορφή αιτήματος που τεκμηριώνει ο πάροχος. Αποθηκεύστε την απάντηση και διακρίνετε την επιτυχή καταχώριση από τη μεταγενέστερη διαθεσιμότητα συμβάντων του μεταφορέα.
3. Κατηγοριοποιήστε τις αποτυχίες. Διαχωρίστε τα μη έγκυρα δεδομένα εισόδου και τα προβλήματα ελέγχου ταυτότητας από τις προσωρινές αποτυχίες υπηρεσίας. Επαναλάβετε μόνο όταν υπάρχει εύλογη πιθανότητα να βοηθήσει η επανάληψη.
4. Λάβετε ή ανακτήστε ενημερώσεις. Υλοποιήστε τον μηχανισμό παράδοσης που υποστηρίζει το επιλεγμένο API. Αν χρησιμοποιείτε webhooks, επικυρώστε τα εισερχόμενα αιτήματα με τη μέθοδο που τεκμηριώνει ο πάροχος και επεξεργαστείτε τα αποδεκτά συμβάντα μέσω ανθεκτικής ουράς.
5. Καταργήστε τα διπλότυπα πριν εφαρμόσετε αλλαγές. Χρησιμοποιήστε αναγνωριστικό συμβάντος του παρόχου, όταν είναι διαθέσιμο, ή ένα προσεκτικά σχεδιασμένο σύνθετο κλειδί. Η επαναλαμβανόμενη παράδοση δεν πρέπει να ενεργοποιεί επαναλαμβανόμενες ειδοποιήσεις πελατών.
6. Επανυπολογίστε την κατάσταση της αποστολής. Αξιολογήστε τη σημασία και τη χρονική ακολουθία των συμβάντων αντί να αντικαθιστάτε την τρέχουσα κατάσταση με όποια ενημέρωση έφτασε τελευταία.
7. Συμφωνήστε τις ελλιπείς εγγραφές. Όπου το API υποστηρίζει ανάκτηση, χρησιμοποιήστε την για τη διερεύνηση χαμένων ενημερώσεων ή παρωχημένων εγγραφών εντός των ισχυόντων ορίων χρήσης.

Διατηρήστε τον έλεγχο ταυτότητας, τα ονόματα πεδίων και τον χειρισμό σφαλμάτων που αφορούν τον πάροχο μέσα σε έναν adapter. Το σύστημα διαχείρισης παραγγελιών σας θα πρέπει να καταναλώνει το εσωτερικό μοντέλο αποστολής και όχι να εξαρτάται άμεσα από κάθε λεπτομέρεια της απάντησης ενός παρόχου. Αυτός ο διαχωρισμός διευκολύνει επίσης τον έλεγχο μεταγενέστερων αλλαγών API.

Διαχειριστείτε τις διαδρομές διασυνοριακής Τασμανίας χωρίς να επινοείτε βεβαιότητα

Η διασυνοριακή παρακολούθηση χρειάζεται περισσότερο πλαίσιο από μια ακολουθία ετικετών κατάστασης. Η εφαρμογή σας θα πρέπει να διακρίνει ένα συμβάν εξαγωγής, ένα τελωνειακό συμβάν, μια παράδοση μεταξύ μεταφορέων και ένα συμβάν τελικής παράδοσης, όταν τα δεδομένα της πηγής υποστηρίζουν αυτές τις διακρίσεις.

Μην συμπεραίνετε τον εκτελωνισμό από μια γενική σάρωση «σε μεταφορά». Ομοίως, η απουσία πρόσφατης σάρωσης δεν αποδεικνύει ότι το τελωνείο κρατά το δέμα. Ένα χρήσιμο μήνυμα προς τον πελάτη αναφέρει το τελευταίο επιβεβαιωμένο συμβάν και την ώρα του και στη συνέχεια εξηγεί οποιαδήποτε επόμενη ενέργεια μπορεί πράγματι να υποστηρίξει η ομάδα σας.

Διατηρήστε την προέλευση και τον προορισμό ξεχωριστά από την τοποθεσία σάρωσης. Μια αποστολή που ταξιδεύει από την Αυστραλία στη Νέα Ζηλανδία δεν μετατρέπεται σε εγχώρια αποστολή της Νέας Ζηλανδίας απλώς επειδή έλαβε σάρωση άφιξης. Αυτή η διάκριση έχει σημασία για την αναφορά διαδρομής και την ευθύνη διαχείρισης εξαιρέσεων.

Μετατρέψτε τα συμβάντα παρακολούθησης σε χρήσιμες ενημερώσεις πελατών

Η σελίδα που βλέπει ο πελάτης θα πρέπει να απαντά σε τέσσερα ερωτήματα: ποια είναι η πιο πρόσφατη επιβεβαιωμένη κατάσταση, πότε συνέβη, πού καταγράφηκε, αν είναι γνωστό, και αν χρειάζεται να ενεργήσει ο πελάτης;

Διατηρήστε τους κανόνες ειδοποιήσεων ξεχωριστά από τη λήψη συμβάντων. Δεν αξίζει κάθε σάρωση ένα email ή ένα μήνυμα κειμένου. Ορίστε σημαντικές μεταβάσεις, όπως η πρώτη επιβεβαιωμένη μετακίνηση, η απόπειρα παράδοσης, η απαίτηση παραλαβής ή το συμβάν παράδοσης, και καταστείλετε επαναλαμβανόμενες ειδοποιήσεις για την ίδια μετάβαση.

• Παρωχημένη παρακολούθηση: Αναφέρετε πότε έγινε η τελευταία ενημέρωση χωρίς να θεωρείτε τη σιωπή απόδειξη απώλειας.
• Εκτιμήσεις παράδοσης: Διακρίνετε την εκτίμηση του μεταφορέα από την υπόσχεση του εμπόρου. Μην επινοείτε ημερομηνία όταν δεν υπάρχει καμία από τις δύο.
• Εξαιρέσεις: Δώστε συγκεκριμένο επόμενο βήμα, όταν είναι γνωστό, αντί να εμφανίζετε μια ανεξήγητη ετικέτα σφάλματος.
• Αμφισβητήσεις παράδοσης: Διατηρήστε το συμβάν της πηγής και προωθήστε την υπόθεση στην υποστήριξη· μια κατάσταση «παραδόθηκε» από μόνη της δεν επιλύει κάθε διαφωνία πελάτη.

Προστατεύστε τις σελίδες παρακολούθησης όπως και τα διαπιστευτήρια API. Αποφύγετε την έκθεση περιττών διευθύνσεων ή στοιχείων επικοινωνίας, διατηρήστε τα διαπιστευτήρια υπηρεσίας στον διακομιστή και εφαρμόστε ελέγχους πρόσβασης κατάλληλους για τις πληροφορίες που εμφανίζονται.

Εκτελέστε πιλοτική εφαρμογή βάσει διαδρομών πριν από την κυκλοφορία

Δοκιμάστε εγχώριες αποστολές στην Αυστραλία, εγχώριες αποστολές στη Νέα Ζηλανδία, αποστολές από την Αυστραλία στη Νέα Ζηλανδία και από τη Νέα Ζηλανδία στην Αυστραλία, όπου αυτές οι διαδρομές είναι σχετικές με την επιχείρησή σας. Συμπεριλάβετε συνηθισμένες παραδόσεις και λειτουργικές οριακές περιπτώσεις: διαχωρισμένες παραγγελίες, μη αναγνωρισμένους αριθμούς, παραδόσεις μεταξύ μεταφορέων, απόπειρες παράδοσης, συμβάντα παραλαβής, επιστροφές και σαρώσεις που φτάνουν καθυστερημένα.

Χρησιμοποιήστε πραγματικές εγγραφές αποστολών με κατάλληλη άδεια για την επικύρωση μεταφορέων. Χρησιμοποιήστε συνθετικά συμβάντα για να ελέγξετε την ανθεκτικότητα της δικής σας εφαρμογής, αλλά μην αντιμετωπίζετε τα συνθετικά αποτελέσματα ως απόδειξη ζωντανής κάλυψης μεταφορέων.

• Έλεγχος ταυτότητας: Κάθε ενημέρωση φτάνει στη σωστή αποστολή και παραγγελία.
• Έλεγχος χρονολογίας: Τα συμβάντα εκτός σειράς δεν αντιστρέφουν λανθασμένα την πρόοδο παράδοσης.
• Έλεγχος ανάκτησης: Οι προσωρινές αποτυχίες και οι διπλότυπες ενημερώσεις δεν προκαλούν απώλεια δεδομένων ή επαναλαμβανόμενες ειδοποιήσεις.
• Έλεγχος υποστήριξης: Οι υπάλληλοι μπορούν να ελέγξουν το αρχικό συμβάν και να κατανοήσουν την κατάσταση που βλέπει ο πελάτης.
• Εμπορικός έλεγχος: Η αναμενόμενη χρήση ταιριάζει στο επαληθευμένο μοντέλο χρέωσης και στα όρια του λογαριασμού.

Καθορίστε τα όρια αποδοχής πριν αξιολογήσετε την πιλοτική εφαρμογή. Μετρήστε τα αποτελέσματα καταχωρίσεων, τα μη αντιστοιχισμένα συμβάντα, τις καθυστερήσεις επεξεργασίας, τις διπλές ειδοποιήσεις και τις ανεπίλυτες παρωχημένες αποστολές. Διαχωρίστε τις καθυστερήσεις δεδομένων του μεταφορέα από τις καθυστερήσεις μέσα στη δική σας εφαρμογή, ώστε η αποκατάσταση να φτάνει στον σωστό υπεύθυνο.

Η υλοποίηση είναι έτοιμη όταν η ομάδα σας μπορεί να εξηγήσει και να αντιμετωπίσει την ελλιπή παρακολούθηση και όχι απλώς να εμφανίζει επιτυχημένες παραδόσεις. Ένα API απλοποιεί τη συνδεσιμότητα· το μοντέλο αποστολής, οι κανόνες συμβάντων και οι λειτουργικές διαδικασίες σας κάνουν αυτή τη συνδεσιμότητα αξιόπιστη.

Συχνές ερωτήσεις

Αντικαθιστά ένα API παρακολούθησης τις ενοποιήσεις αποστολής με μεταφορείς;

Όχι απαραίτητα. Η παρακολούθηση, η δημιουργία ετικετών, η κράτηση παραλαβής, ο υπολογισμός τιμών και τα τελωνειακά έγγραφα είναι ξεχωριστές λειτουργίες. Επαληθεύστε το εύρος του επιλεγμένου προϊόντος και διατηρήστε άλλες ενοποιήσεις όπου τις χρειάζεται η διαδικασία εκπλήρωσης παραγγελιών σας.

Μπορώ να καταχωρίσω έναν αριθμό παρακολούθησης πριν από την πρώτη σάρωση του μεταφορέα;

Ελέγξτε τους κανόνες καταχώρισης του API. Σχεδιάστε την εφαρμογή σας ώστε να διακρίνει την αποδεκτή καταχώριση παρακολούθησης από την επιβεβαιωμένη φυσική μετακίνηση. Μια εγγραφή χωρίς συμβάντα δεν θα πρέπει να εμφανίζεται αυτόματα ως «σε μεταφορά».

Θα παρέχει ένα ενιαίο API ενημερώσεις σε πραγματικό χρόνο για κάθε μεταφορέα;

Μην το θεωρείτε δεδομένο. Η επικαιρότητα από άκρο σε άκρο εξαρτάται από το πότε ο μεταφορέας δημοσιεύει τα δεδομένα, πότε τα αποκτά η υπηρεσία παρακολούθησης και πότε τα επεξεργάζεται η εφαρμογή σας. Επιβεβαιώστε τη συμπεριφορά ενημερώσεων για τους συνδυασμούς μεταφορέων και υπηρεσιών που χρησιμοποιείτε.

Τι πρέπει να συμβαίνει όταν αλλάζει ο αριθμός παρακολούθησης;

Διατηρήστε το αρχικό αναγνωριστικό και συνδέστε το επαληθευμένο αναγνωριστικό αντικατάστασης ή συνεργάτη με την ίδια εσωτερική αποστολή. Διατηρήστε και τα δύο ιστορικά και αποτρέψτε τη δημιουργία αντικρουόμενων ειδοποιήσεων από διπλότυπες εγγραφές.

Είναι το 17TRACK σχετικό με αυτή την ενοποίηση;

Ναι. Το Tracking API του είναι σχετικό με την ενοποίηση πολλαπλών μεταφορέων που περιγράφεται εδώ. Αξιολογήστε το χρησιμοποιώντας δείγματα αποστολών από την Αυστραλία και τη Νέα Ζηλανδία και επιβεβαιώστε την υποστήριξη μεταφορέων, την τεχνική συμπεριφορά και τους όρους λογαριασμού μέσω των επίσημων πόρων API πριν από την ανάπτυξη.

Πηγές

• 17TRACK Tracking API — επίσημος πόρος προϊόντος για την επιλογή API που συζητείται σε αυτόν τον οδηγό.
• 17TRACK API documentation — επίσημη τεχνική αναφορά για τον έλεγχο μορφών αιτημάτων, απαιτήσεων ενοποίησης και υποστηριζόμενης συμπεριφοράς.