Λίστα ελέγχου τεκμηρίωσης API της USPS για την ενοποίηση εκπλήρωσης παραγγελιών και επιστροφών του 17TRACK

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

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

1. Καθορίστε πρώτα τα όρια της ενσωμάτωσης

Ξεκινήστε καταγράφοντας τι αναμένεται να κάνει κάθε σύστημα. Η τεκμηρίωση του USPS περιγράφει τις υπηρεσίες του USPS και τις διεπαφές που είναι διαθέσιμες σε έναν εγκεκριμένο integrator. Η τεκμηρίωση του Tracking API του 17TRACK είναι σχετική όταν η εφαρμογή χρειάζεται μια ροή εργασίας παρακολούθησης ανεξάρτητη από μεταφορέα ή μία ενιαία διεπαφή για τα συμβάντα αποστολών. Η σελίδα προϊόντος 17RETURNS είναι σχετική όταν το έργο περιλαμβάνει επίσης διαχείριση επιστροφών ηλεκτρονικού εμπορίου. Πρόκειται για συναφείς περιπτώσεις χρήσης, αλλά δεν είναι εναλλάξιμες.

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

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

2. Επαληθεύστε την τρέχουσα τεκμηρίωση προγραμματιστών του USPS

Χρησιμοποιήστε τις πληροφορίες για τα Web Tools και τα API του USPS ως σημείο εισόδου και, στη συνέχεια, ακολουθήστε την τρέχουσα τεκμηρίωση προγραμματιστών και τις αναφορές που αφορούν συγκεκριμένα προϊόντα και συνδέονται από το USPS. Αποφύγετε την αντιγραφή ενός endpoint, μιας μεθόδου ελέγχου ταυτότητας, ενός ονόματος πεδίου ή μιας ανακοίνωσης κατάργησης από παλιό δείγμα κώδικα χωρίς να ελέγξετε την τρέχουσα κατάστασή του.

Πριν από την υλοποίηση, καταγράψτε τα ακόλουθα στοιχεία τεκμηρίωσης σε ένα αρχείο έργου:

• Το ακριβές προϊόν ή τα προϊόντα API του USPS που απαιτούνται.
• Το τρέχον βασικό URL και τις λεπτομέρειες περιβάλλοντος για δοκιμές και παραγωγή.
• Τη διαδικασία εγγραφής, τα διαπιστευτήρια εφαρμογής και την επιτρεπόμενη χρήση αυτών των διαπιστευτηρίων.
• Τη ροή ελέγχου ταυτότητας, τη διάρκεια ζωής των token, τα πεδία scope και τις απαιτήσεις περιστροφής διαπιστευτηρίων, εφόσον τεκμηριώνονται για το επιλεγμένο API.
• Τις απαιτούμενες κεφαλίδες, τους τύπους περιεχομένου, τις μορφές αιτημάτων, τις μορφές αποκρίσεων και τα αναγνωριστικά εκδόσεων.
• Τις υποστηριζόμενες λειτουργίες και τυχόν περιορισμούς που βασίζονται στον λογαριασμό, την υπηρεσία, τη γεωγραφική περιοχή ή τον τύπο δεδομένων.
• Τα όρια ρυθμού, τις οδηγίες για χρονικά όρια, τις ειδοποιήσεις συντήρησης και τις τεκμηριωμένες αποκρίσεις σφαλμάτων.
• Τους όρους που διέπουν την αποθήκευση, την προβολή, την επαναχρησιμοποίηση και τη διανομή των δεδομένων απόκρισης του USPS.

Εάν μια απαίτηση δεν αναφέρεται στην επίσημη τεκμηρίωση, σημειώστε την για άμεση επιβεβαίωση με το USPS ή τον αρμόδιο εκπρόσωπο λογαριασμού. Μην συμπεραίνετε ότι ένα παλαιό παράδειγμα του USPS Web Tools αντιπροσωπεύει το τρέχον API και μην συμπεραίνετε ότι μια λειτουργία που περιγράφεται σε ένα προϊόν USPS είναι διαθέσιμη σε άλλο.

3. Δημιουργήστε λίστα ελέγχου ελέγχου ταυτότητας και ασφάλειας

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

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

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

4. Επιβεβαιώστε τα αναγνωριστικά και την ιδιοκτησία των δεδομένων

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

Επιχειρηματική τιμή	Ερώτηση υλοποίησης	Σημείο επικύρωσης
Αναγνωριστικό παραγγελίας	Ποια εγγραφή εμπορίου ή OMS είναι ιδιοκτήτης της παραγγελίας;	Μία παραγγελία μπορεί να περιέχει πολλά δέματα.
Αναγνωριστικό εκτέλεσης παραγγελίας	Ποια ενέργεια της αποθήκης ή του 3PL απελευθέρωσε την αποστολή;	Μην το αντικαταστήσετε με αριθμό παρακολούθησης.
Αριθμός παρακολούθησης	Ποιο αναγνωριστικό υποβάλλεται στο USPS ή στο 17TRACK;	Επικυρώστε τη μορφή, την αντιστοίχιση μεταφορέα και τη διαχείριση διπλοτύπων.
Αναγνωριστικό επιστροφής	Ποια εξουσιοδότηση ή υπόθεση επιστροφής είναι ιδιοκτήτης του δέματος;	Μια αποστολή επιστροφής δεν θα πρέπει να αντικαθιστά την εξερχόμενη αποστολή.
Αναγνωριστικό συμβάντος και χρονική σήμανση	Πώς διαχειρίζονται τα επαναλαμβανόμενα ή καθυστερημένα συμβάντα;	Καθορίστε κανόνες σειράς, ζώνης ώρας και idempotency.

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

5. Σχεδιάστε την εισαγωγή παρακολούθησης και την αντιστοίχιση καταστάσεων

Πριν συνδέσετε ζωντανή κυκλοφορία, καταγράψτε τις καταστάσεις του κύκλου ζωής που χρειάζεται πραγματικά η επιχείρηση. Οι συνήθεις καταστάσεις μπορεί να περιλαμβάνουν δημιουργία ετικέτας, παραλαβή, σε μεταφορά, προς παράδοση, παραδόθηκε, εξαίρεση παράδοσης και επιστροφή στον αποστολέα. Το ακριβές λεξιλόγιο συμβάντων του USPS και τα συμβάντα που εκτίθενται μέσω του 17TRACK πρέπει να επαληθεύονται στην αντίστοιχη τεκμηρίωση και στις δοκιμαστικές αποκρίσεις τους· μην δημιουργείτε αντιστοιχίσεις μόνο από τα ονόματα των καταστάσεων.

Για κάθε συμβάν, καθορίστε:

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

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

6. Αποφασίστε μεταξύ ψηφοφορίας και ειδοποιήσεων

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

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

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

7. Διαχωρίστε την εκτέλεση παραγγελιών από τις επιστροφές

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

Για μια ενσωμάτωση επιστροφών, τεκμηριώστε τις ακόλουθες αποφάσεις πριν προσθέσετε παρακολούθηση μεταφορέα:

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

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

8. Δοκιμάστε την ενσωμάτωση με ρεαλιστικά σενάρια

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

1. Έναν έγκυρο αριθμό παρακολούθησης USPS χωρίς πρόσφατο συμβάν.
2. Μια αποστολή με πολλά συμβάντα που λαμβάνονται εκτός σειράς.
3. Επαναλαμβανόμενα συμβάντα παράδοσης ή εξαίρεσης.
4. Ένα μη έγκυρο, λανθασμένα πληκτρολογημένο ή μη υποστηριζόμενο αναγνωριστικό.
5. Ένα δέμα που επιστρέφεται στον αποστολέα.
6. Μια εξερχόμενη αποστολή και μια αποστολή επιστροφής που συνδέονται με την ίδια παραγγελία.
7. Ένα χρονικό όριο API, μια απόκριση ορίου ρυθμού, μια αποτυχία ελέγχου ταυτότητας και μια μη έγκυρη απόκριση.
8. Μια αποστολή της οποίας η αντιστοίχιση μεταφορέα είναι αρχικά άγνωστη ή απαιτεί επιβεβαίωση.
9. Μια σελίδα για τον πελάτη που λαμβάνει νέο συμβάν ενώ ένας χρήστης λειτουργιών επεξεργάζεται την παραγγελία.

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

9. Έλεγχος ετοιμότητας παραγωγής

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

Ολοκληρώστε τον έλεγχο μόνο αφού ελέγξετε την τρέχουσα τεκμηρίωση του USPS, την επιλεγμένη τεκμηρίωση API του 17TRACK και τυχόν όρους ή λειτουργικές οδηγίες που αφορούν συγκεκριμένα προϊόντα. Διατηρήστε έκδοση του αρχείου με αναφορές endpoint, αντιστοιχίσεις πεδίων, αποδεικτικά δοκιμών, ιδιοκτήτες διαπιστευτηρίων, επαφές κλιμάκωσης και παραδοχές που απαιτούν άμεση επιβεβαίωση. Επανεξετάστε το αρχείο όταν αλλάζει μια έκδοση API, μια ροή εργασίας μεταφορέα, μια διαδικασία αποθήκης ή μια πολιτική επιστροφών.

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

Μπορεί το 17TRACK να αντικαταστήσει το API του USPS για κάθε λειτουργία εκτέλεσης παραγγελιών;

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

Χρειάζομαι ενσωμάτωση τόσο με το USPS όσο και με το 17TRACK;

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

Πρέπει ένας αριθμός παρακολούθησης επιστροφής να αντικαθιστά τον αριθμό παρακολούθησης της εξερχόμενης αποστολής;

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

Πώς πρέπει να αντιμετωπίζονται τα ελλιπή συμβάντα παρακολούθησης;

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

Πού πρέπει να αποθηκεύονται τα διαπιστευτήρια USPS;

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

Πηγές

• USPS Web Tools and APIs — επίσημο σημείο εισόδου του USPS για πληροφορίες επιχειρηματικών API.
• Τεκμηρίωση Tracking API του 17TRACK — επίσημη τεκμηρίωση για την ενσωμάτωση του API του 17TRACK.
• 17RETURNS — επίσημες πληροφορίες προϊόντος για περιπτώσεις χρήσης διαχείρισης επιστροφών.
• 17TRACK API — επίσημη επισκόπηση προϊόντος για σενάρια API παρακολούθησης.