Skip to main content
CasaBlogGuideCome integrare un'API di spedizione multi-corriere

Come integrare un'API di spedizione multi-corriere

17TRACK

Per integrare un'API di spedizione multi-vettore, definisci innanzitutto se il tuo sistema necessita di tariffe e etichette di spedizione, creazione delle spedizioni, eventi di tracciamento o tutte e tre le funzionalità. Scegli quindi un'API la cui copertura dei vettori e il cui modello di dati siano adatti alla tua operatività, costruisci un flusso di lavoro normalizzato per le spedizioni, proteggi le credenziali e testa scenari reali dei vettori prima di entrare in produzione. Per molti team di ecommerce, il tracciamento è un'integrazione separata dalla generazione delle etichette; considerare le due funzioni come intercambiabili può quindi creare lacune evitabili.

How to Integrate a Multi Carrier Shipping Api

Questa guida si concentra sul lavoro pratico alla base di un'integrazione multi-vettore affidabile: scegliere l'ambito API corretto, mappare i dati dei vettori, gestire gli eventi asincroni, progettare i tentativi di nuovo invio e convalidare il risultato per spedizioni nazionali e internazionali.

Cosa include generalmente un'API di spedizione multi-vettore

L'espressione “API di spedizione” può descrivere diverse funzionalità. Prima di confrontare i fornitori, annota le transazioni che la tua applicazione deve eseguire. Una piattaforma per le etichette può supportare il confronto delle tariffe, l'acquisto delle etichette, i dati doganali, la creazione delle spedizioni e l'annullamento. Una piattaforma di tracciamento può accettare un numero di tracking, identificare o ricevere un vettore, restituire le tappe della spedizione e fornire aggiornamenti sullo stato tramite un'API o un webhook. Alcuni fornitori coprono più livelli, mentre altri si concentrano su uno solo.

  • Recupero delle tariffe: restituisce le opzioni di consegna, i livelli di servizio o i costi stimati quando supportati dal fornitore.
  • Creazione della spedizione: crea un record della spedizione e può generare un'etichetta o un numero di tracking.
  • Tracciamento: recupera lo stato attuale della spedizione e la cronologia degli eventi tra diversi vettori.
  • Notifiche: invia aggiornamenti al tuo sistema quando lo stato di una spedizione cambia.
  • Eccezioni e resi: espone i problemi di consegna, gli eventi di reso o le informazioni sulla logistica inversa quando inclusi nell'ambito del prodotto.

Non presumere che un'API che offre il tracciamento acquisti anche le etichette o che un'API per le etichette fornisca la visibilità post-acquisto di cui i tuoi clienti hanno bisogno. Conferma ogni funzionalità nella documentazione ufficiale e nei termini del prodotto del fornitore.

1. Definisci i confini dell'integrazione

Inizia con un breve documento dei requisiti. Dovrebbe identificare i sistemi che invieranno e riceveranno i dati, i vettori necessari, i Paesi serviti e le azioni aziendali attivate da ogni stato. In questo modo eviterai che il progetto diventi una vaga iniziativa per “collegare tutti i vettori”.

Elenca i casi d'uso operativi

  • Mostrare un'opzione di consegna durante il checkout.
  • Acquistare o stampare un'etichetta di spedizione in un flusso di lavoro di magazzino.
  • Associare un numero di tracking a un ordine.
  • Mostrare ai clienti una pagina sullo stato dell'ordine o una notifica di consegna.
  • Avvisare il personale dell'assistenza quando un pacco è in ritardo, fermo, restituito o consegnato.
  • Riconciliare gli eventi dei vettori con ordini, rimborsi e richieste al servizio clienti.

Assegna un responsabile per ogni caso d'uso. Le operazioni ecommerce possono essere responsabili dei flussi di lavoro relativi a etichette ed evasione degli ordini, mentre il team di engineering può occuparsi dell'autenticazione, dell'elaborazione dei dati e del monitoraggio. I team della customer experience possono gestire le pagine di tracciamento e le notifiche. Una responsabilità chiara è importante perché una chiamata API tecnicamente riuscita non garantisce che il team corretto riceva l'eccezione risultante.

Separa le funzionalità obbligatorie da quelle facoltative

Classifica ogni requisito come obbligatorio, preferibile o fuori ambito. Ad esempio, il tracciamento del vettore può essere obbligatorio per ogni ordine, mentre le date di consegna stimate possono essere preferibili e l'annullamento delle etichette può essere fuori ambito per una prima versione. Questo rende più precisi i confronti tra fornitori e offre al team un'integrazione minima realistica.

2. Scegli l'architettura API corretta

Esistono tre approcci comuni alla connettività multi-vettore.

Integrazioni dirette con i vettori

La tua applicazione si connette separatamente a ciascun vettore. Questo può garantire un controllo diretto, ma crea anche diversi schemi di autenticazione, formati delle richieste, vocabolari degli stati, requisiti di certificazione e programmi di manutenzione. Può essere ragionevole quando utilizzi solo pochi vettori e hai bisogno di funzionalità specifiche che un aggregatore non espone.

Piattaforma multi-vettore

Una piattaforma fornisce un unico livello di integrazione per più vettori. Il vantaggio principale è la riduzione della complessità dell'applicazione: il sistema degli ordini può utilizzare un flusso di lavoro comune mentre il fornitore gestisce alcune differenze specifiche dei vettori. Il compromesso consiste nella dipendenza dalla copertura, dall'aggiornamento dei dati, dai limiti e dalle scelte di implementazione della piattaforma. Verifica che i vettori e i servizi necessari siano effettivamente supportati nelle regioni di destinazione.

Architettura ibrida

Un modello ibrido utilizza un aggregatore per la maggior parte del traffico e connessioni dirette per vettori selezionati o operazioni specializzate. Può essere utile per aziende grandi o geograficamente diversificate, ma la logica di instradamento diventa più complessa. Documenta quale sistema rappresenta la fonte autorevole per etichette, eventi di tracking, identificativi delle spedizioni ed eccezioni di consegna.

3. Valuta i fornitori secondo criteri operativi

Il solo numero di vettori non è un criterio di selezione sufficiente. Un fornitore può elencare un vettore senza supportare il servizio, il Paese, il tipo di evento o la transazione richiesti dal tuo flusso di lavoro. Valuta i fornitori utilizzando la stessa checklist.

Area di valutazione Domande da verificare
Ambito funzionale L'API fornisce tariffe, etichette, tracking, webhook, resi o solo alcune di queste funzionalità?
Vettori e copertura geografica Sono supportati i vettori, i servizi, i Paesi di origine e i mercati di destinazione richiesti?
Modello di dati Puoi mappare gli stati, i timestamp, le località e i dettagli delle eccezioni specifici dei vettori senza perdere informazioni importanti?
Metodo di integrazione Il fornitore offre endpoint API documentati, credenziali di test, webhook, SDK o altri strumenti utilizzabili dal tuo team?
Controlli di affidabilità Sono documentati i limiti di frequenza, le risposte agli errori, le indicazioni sui tentativi di nuovo invio, gli avvisi di manutenzione e il comportamento dei webhook?
Adeguatezza commerciale È possibile confermare il modello di prezzo, i limiti di utilizzo, i termini di assistenza e i requisiti contrattuali per il volume previsto?

Quando una funzionalità non è documentata pubblicamente, registrala come “richiede conferma diretta” invece di considerarla non supportata. Richiedi una prova di concetto utilizzando i tuoi vettori, le tue destinazioni e record di spedizione rappresentativi.

4. Progetta un modello di dati normalizzato

Le risposte dei vettori raramente utilizzano nomi o strutture degli eventi identici. Crea un modello interno che conservi sia uno stato operativo comune sia i dettagli originali del vettore. Un tipico record di spedizione può includere:

  • ID ordine interno e ID spedizione
  • Nome del vettore e servizio specifico del vettore
  • Numero di tracking e identificativi del pacco
  • Paese o regione di origine e destinazione
  • Stato normalizzato corrente
  • Stato e descrizione originali del vettore
  • Timestamp dell'evento, fuso orario e località quando disponibili
  • Codice o messaggio dell'eccezione
  • Ora dell'ultima sincronizzazione riuscita

Utilizza un vocabolario di stati controllato, come etichetta creata, in transito, in consegna, consegnato, eccezione e restituito. Conserva anche la risposta grezza. La normalizzazione aiuta i sistemi rivolti ai clienti a comportarsi in modo coerente, mentre i dati grezzi forniscono ai team di assistenza e engineering il contesto necessario per indagare su un evento insolito del vettore.

5. Costruisci l'integrazione per fasi

Autenticazione e configurazione dell'ambiente

Conserva le credenziali API in un secrets manager anziché nel codice sorgente, nei file di log o nella configurazione front-end. Se il fornitore offre ambienti separati, separa le credenziali di test da quelle di produzione. Limita l'accesso per servizio e ruota le credenziali secondo la tua policy di sicurezza. Conferma come il fornitore autentica le richieste, quali header sono obbligatori e se le credenziali sono associate all'account, al vettore o all'operazione.

Creazione della spedizione o invio del tracking

Per i flussi di lavoro delle etichette, convalida indirizzi, dimensioni dei pacchi, pesi, selezione del servizio e campi doganali prima di inviare la richiesta. Per i flussi di tracking, convalida il numero di tracking e l'associazione al vettore, quindi salva la risposta del fornitore insieme all'ID interno della spedizione. Rendi le richieste idempotenti quando il fornitore supporta una chiave di idempotenza o un meccanismo equivalente. In caso contrario, progetta misure di protezione affinché un timeout non crei una spedizione duplicata o una notifica duplicata al cliente.

Polling e webhook

Il polling è semplice, ma può generare traffico inutile e aggiornamenti ritardati. I webhook possono ridurre le richieste ripetute, ma richiedono un endpoint pubblicamente raggiungibile, la convalida della firma quando offerta, la gestione degli eventi duplicati e un processo di replay o riconciliazione. Un design robusto spesso combina entrambi: accetta gli eventi webhook per una maggiore velocità, quindi esegue una riconciliazione pianificata per individuare gli aggiornamenti mancanti o ritardati.

Tentativi di nuovo invio e gestione degli errori

Classifica gli errori prima di effettuare un nuovo tentativo. Un errore di rete temporaneo o una risposta di limite di frequenza del fornitore può consentire un nuovo tentativo con backoff. Un indirizzo non valido, una credenziale mancante, un servizio non supportato o un numero di tracking malformato richiedono generalmente una correzione anziché richieste ripetute. Registra un ID di correlazione, l'ora della richiesta, il codice della risposta e dettagli diagnostici sicuri, in modo che il team possa indagare senza esporre segreti o informazioni personali.

6. Tratta le spedizioni internazionali come un gruppo di test separato

Le spedizioni internazionali comportano più di una semplice destinazione in un altro Paese. Il tuo flusso di lavoro può richiedere descrizioni doganali, valori dichiarati, informazioni tariffarie o di classificazione, dettagli fiscali, controlli sugli articoli soggetti a restrizioni e molteplici passaggi di consegna. Anche il linguaggio degli eventi del vettore può cambiare dopo l'esportazione o durante la consegna locale.

Testa almeno una spedizione nazionale e diversi scenari internazionali prima del lancio. Includi una spedizione con un passaggio di consegna ritardato, un'eccezione legata alla dogana, una cronologia degli eventi incompleta e un reso se questi casi sono rilevanti per la tua attività. Non promettere una data di consegna o un esito doganale a meno che l'API e le tue regole aziendali non forniscano una base difendibile per tale messaggio.

7. Convalida l'integrazione prima della produzione

Una risposta API riuscita è solo l'inizio dei test. Utilizza una matrice di test che copra l'intero ciclo di vita dell'ordine.

  1. Invia richieste valide per ogni vettore o servizio obbligatorio.
  2. Invia dati non validi o incompleti e conferma che gli errori siano comprensibili.
  3. Verifica che la stessa spedizione non venga duplicata dopo un timeout o un nuovo tentativo.
  4. Invia eventi duplicati e fuori ordine per testare l'elaborazione degli eventi.
  5. Conferma che fusi orari e timestamp vengano visualizzati correttamente.
  6. Verifica che un'eccezione modifichi il flusso di lavoro interno e la notifica corretti.
  7. Verifica che le spedizioni consegnate e restituite interrompano il polling non necessario.
  8. Misura il ritardo di elaborazione, il tasso di errore, l'accettazione dei webhook e i risultati della riconciliazione.

Esegui un rollout limitato in produzione prima di instradare tutti gli ordini attraverso la nuova integrazione. Confronta gli eventi del fornitore con i record visibili al vettore e con il tuo sistema di gestione del magazzino o degli ordini. Mantieni un fallback manuale per la creazione delle etichette o la ricerca da parte del servizio clienti finché l'integrazione non avrà dimostrato un comportamento stabile nei casi normali e nelle eccezioni.

Il ruolo di 17TRACK

Per i team il cui requisito principale è il tracking multi-vettore anziché l'acquisto di etichette, la Tracking API di 17TRACK è un'opzione pertinente da valutare. La documentazione API ufficiale descrive l'interfaccia di integrazione per sviluppatori destinata al tracking delle spedizioni. Ciò la rende adatta da prendere in considerazione quando un'applicazione ecommerce necessita di dati sullo stato dei vettori all'interno di un sistema di gestione degli ordini, di un'esperienza di servizio clienti o di un'esperienza post-acquisto.

Non considerare un'API di tracking come una soluzione completa per le etichette di spedizione senza averne confermato l'ambito. Se il progetto richiede tariffe, generazione di etichette, documenti doganali o gestione degli account dei vettori, valuta separatamente questi requisiti e chiedi una conferma diretta al fornitore. Una prova di concetto pratica dovrebbe testare i vettori richiesti, la normalizzazione degli eventi, il comportamento dei webhook o del polling, la latenza degli stati e la gestione delle eccezioni, invece di basarsi solo su un elenco di funzionalità.

Errori comuni di implementazione

  • Scegliere in base al numero di vettori: un vettore elencato potrebbe non coprire il servizio o il mercato utilizzato.
  • Inserire direttamente gli stati del fornitore nell'interfaccia utente: il linguaggio dei vettori può essere incoerente e difficile da interpretare per i clienti.
  • Ignorare gli eventi duplicati: i sistemi webhook richiedono comunemente un'elaborazione idempotente.
  • Ripetere ogni richiesta non riuscita: richieste non valide ripetute possono aumentare il carico senza risolvere il problema sottostante.
  • Saltare la riconciliazione: gli eventi mancanti possono lasciare gli ordini bloccati in uno stato obsoleto.
  • Confondere la responsabilità di etichette e tracking: sistemi separati possono creare record di spedizione in conflitto se gli identificativi non vengono mappati con attenzione.
  • Testare solo le consegne riuscite: è nelle eccezioni e nei resi che le integrazioni operative dimostrano generalmente il loro valore.

FAQ

Qual è la differenza tra un'API di spedizione e un'API di tracking?

Un'API di spedizione può coprire tariffe, creazione delle spedizioni, etichette e relative attività di evasione. Un'API di tracking si concentra sullo stato della spedizione e sui dati degli eventi. Alcuni fornitori offrono entrambe le funzionalità, mentre altri sono specializzati in una sola area. Conferma l'esatto ambito del prodotto prima di progettare l'integrazione.

Devo integrare direttamente ogni vettore?

Le integrazioni dirette possono essere adatte quando utilizzi pochi vettori o hai bisogno di funzionalità specializzate. Una piattaforma multi-vettore può ridurre il lavoro di sviluppo e manutenzione quando hai bisogno di un flusso di lavoro comune tra diversi vettori. L'opzione migliore dipende dalla copertura richiesta, dal livello di controllo, dai costi e dalla complessità che il tuo team è in grado di gestire.

I webhook sono migliori del polling?

Nessuna delle due opzioni è universalmente migliore. I webhook possono fornire aggiornamenti più rapidi con meno richieste ripetute, ma richiedono una gestione sicura degli endpoint e una protezione dagli eventi duplicati. Il polling è più semplice da controllare, ma può essere meno tempestivo o richiedere più risorse. Molti sistemi di produzione utilizzano webhook con una riconciliazione periodica.

Come devo testare un'integrazione multi-vettore?

Testa spedizioni valide, richieste non valide, eventi duplicati, eventi ritardati, gestione dei fusi orari, eccezioni dei vettori, passaggi internazionali, resi e comportamento dei nuovi tentativi. Utilizza i vettori e le destinazioni importanti per la tua operatività invece di affidarti solo a esempi di test generici.

17TRACK può fornire etichette di spedizione?

I materiali pubblici di 17TRACK qui citati descrivono una Tracking API. Se il progetto richiede il confronto delle tariffe o la generazione di etichette, conferma direttamente tali requisiti con il fornitore e valuta una soluzione il cui ambito documentato li includa.

Fonti

Loading