Seuranta-API vs. toimitus-API: Kumpaa verkkokauppasi teknologiapino tarvitsee (vai molempia)?

Käytä shipping API -rajapintaa, kun verkkokauppasi tarvitsee lähetysten luomista ja lähetysosoitekorttien tuottamista. Käytä tracking API -rajapintaa, kun sen on seurattava lähetyksiä niiden lähettämisen jälkeen ja muutettava kuljetusyhtiöiden päivitykset hyödyllisiksi operatiivisiksi tai asiakkaalle näkyviksi tiedoiksi. Tarvitset molemmat ominaisuudet, jos ohjelmistosi on hallittava lähetysten luomista ja ostoksen jälkeistä näkyvyyttä, mutta et välttämättä tarvitse kahta palveluntarjoajaa tai kahta erillistä integraatiota.

Päätöksen tekee toimitusarkkitehtuurista vastaava henkilö: yleensä verkkokaupan operatiivinen johtaja yhteistyössä teknisen tiimin kanssa. Aloita selvittämällä, mitä myymäläsi, varastosi tai toimituskumppanisi jo hoitaa. Uuden API:n lisäämisen pitäisi poistaa tietty puute, ei monistaa jo toimivaa työnkulkua.

Mikä ero on tracking API - ja shipping API -rajapinnoilla?

Ero liittyy ensisijaisesti siihen, mitä tehtävää kukin API suorittaa, ei jäykkään rajaan tuoteryhmien välillä. Toimitusalusta voi sisältää seurantapäätepisteitä, ja seurantapalvelu voi tarjota työkaluja ilmoituksiin ja asiakkaalle näkyviin toimituspäivityksiin. Arvioi dokumentoidut päätepisteet ja tapahtumien toiminta sen sijaan, että luottaisit tuotteen nimeen.

Päätöksen ulottuvuus	Tracking API	Shipping API
Päätehtävä	Lähetyksen tilan ja seurantatapahtumien hakeminen tai vastaanottaminen.	Lähetysten luominen sekä osoitekorttien ja niihin liittyvien lähetysasiakirjojen hankkiminen.
Tyypilliset syötteet	Seurantanumero, kuljetusyhtiön tunniste ja muut vaaditut lähetyksen tiedot.	Lähettäjän ja vastaanottajan tiedot, paketin tiedot, palvelun valinta ja soveltuvat tullitiedot.
Tyypilliset tulosteet	Lähetyksen tila, tapahtumahistoria ja muut saatavilla olevat toimitustiedot.	Lähetystunnisteet, osoitekortit ja tuetut asiakirjat.
Pääasiallinen työnkulku	Toimituksen näkyvyys, poikkeamien käsittely ja oston jälkeiset päivitykset.	Varaston lähetys ja lähtevän lähetyksen valmistelu.
Mitä ei pidä olettaa	Seurannan käyttöoikeus ei välttämättä sisällä osoitekorttien luomista tai kuljetusyhtiön varausta.	Osoitekorttien luominen ei välttämättä sisällä tarvitsemaasi seurannan yksityiskohtaisuutta ja ilmoitusten hallintaa.

Kuljetusyhtiöiden dokumentaatio havainnollistaa tätä eroa. FedEx dokumentoi lähetysten luomisen Ship API -dokumentaatiossaan ja seurantatoiminnot tracking API -dokumentaatiossaan. Nämä ovat esimerkkejä erilaisista teknisistä vastuista, eivät suositus tietyn kuljetusyhtiön valitsemiseksi.

Lähetyksen luominen ei ole sama asia kuin sen liikkeen seuraaminen

Onnistunut lähetyksen luomisesta saatu vastaus kertoo ohjelmistollesi, että lähetyspyyntö käsiteltiin. Se ei vahvista, että kuljetusyhtiö on fyysisesti vastaanottanut paketin. Vastaavasti seurantanumero voi olla olemassa ennen kuin liike näkyy seurantahistoriassa.

Tilaustenhallintajärjestelmäsi pitäisi siksi erottaa toisistaan osoitekortin luominen, luovutus varastolta, kuljetusyhtiön vastaanotto ja toimitus. Jos kaikki nämä käsitellään yhtenä ”lähetetty”-tapahtumana, asiakkaille voidaan lähettää ennenaikaisia viestejä ja varastolta tosiasiassa lähtemättä jääneet paketit voivat jäädä huomaamatta.

Valitse ominaisuus, joka poistaa nykyisen pullonkaulasi

Valitse shipping API, kun lähetys on puuttuva osa

Shipping API on oikea lähtökohta, kun oman sovelluksesi on muutettava tilaustiedot lähetykseksi. Esimerkkejä ovat tilanne, jossa varastotiimi kopioi osoitteet manuaalisesti kuljetusyhtiöiden portaaleihin, tai mukautettu tilaustenhallintajärjestelmä, joka ei pysty luomaan osoitekortteja.

Määritä todellinen lähetysprosessi ennen integraation valintaa. Tarvitsetko vain lähetyksen luomisen vai myös hintojen hakemisen, peruutukset, noutopyynnöt, tulliasiakirjat tai päivän päätösprosessit? Nämä toiminnot voivat olla erillisiä API-rajapintoja, riippua kuljetusyhtiöstä tai edellyttää lisäoikeuksia tilille. Älä oleta, että ”shipping API” -niminen tuote sisältää kaikki lähetyksiin liittyvät toiminnot.

Ei ihanteellinen ainoaksi ratkaisuksi: osoitekorttien luomiseen tarkoitettu integraatio, joka jättää asiakaspalvelutiimisi tarkistamaan yksittäisten kuljetusyhtiöiden verkkosivustoja. Se voi ratkaista lähettämisen, mutta jättää toimitusten näkyvyyden pitkälti ennalleen.

Valitse tracking API, kun lähetysten luominen toimii jo

Tracking API sopii suoremmin tilanteeseen, jossa varastonhallintajärjestelmäsi, toimituskumppanisi, markkinapaikkasi tai nykyinen lähetysintegraatiosi luo jo osoitekortit, mutta toimitustiedot ovat hajallaan.

Tällaisessa tilanteessa osoitekorttien työnkulun korvaaminen voi lisätä siirtotyötä ratkaisematta keskeistä ongelmaa. Yhdistä sen sijaan ylemmällä tasolla luodut seurantanumerot näkyvyyskerrokseen, jota tilaustenhallintajärjestelmäsi, tukityökalusi ja asiakasviestintäsi voivat käyttää.

Tässä kategoriassa 17TRACK Tracking API on varteenotettava integraatiovaihtoehto. Sen virallinen API-dokumentaatio kuvaa seurantanumeroiden rekisteröinnin ja seurantatietojen työnkulut, mukaan lukien push-ilmoitukset. Arvioi näitä työnkulkuja suhteessa tarvitsemiisi kuljetusyhtiöihin, lähetystyyppeihin ja sovellusarkkitehtuuriin. Kyse on seurantakerroksesta, ei osoituksesta, että palvelu korvaisi osoitekorttien luomiseen tarkoitetun integraation.

Ei ihanteellinen ainoaksi ratkaisuksi: tracking API tilanteessa, jossa ohjelmistollasi ei edelleenkään ole tapaa luoda lähetyksiä, joiden lähettämisestä se vastaa. Seurannan näkyvyys ei ratkaise puuttuvaa lähetyksen toteutusta.

Käytä molempia, kun sovelluksesi vastaa lähettämisestä ja toimitusten näkyvyydestä

Molemmat ominaisuudet ovat tarpeen, kun järjestelmäsi on luotava osoitekortit ja ylläpidettävä sen jälkeen luotettavaa näkymää lähetyksen etenemiseen. Ne voivat tulla yhdeltä alustalta, erillisistä palveluista tai kuljetusyhtiöintegraatioiden ja seurantakerroksen yhdistelmästä.

Suosi yhtä integraatiota, kun sen lähetys- ja seurantatoiminnot täyttävät dokumentoidut vaatimuksesi ilman tarpeettomia kompromisseja. Harkitse erillisiä integraatioita, kun olemassa oleva lähetysprosessi kannattaa säilyttää tai kun seurantavaatimukset poikkeavat olennaisesti nykyisen työnkulun tarjoamista ominaisuuksista. Erillinen seurantapalveluntarjoaja ei ole automaattisesti parempi; sen on perusteltava lisäintegraatio, laskutus ja operatiivinen vastuu.

Miten molemmat API:t sopivat verkkokauppasi järjestelmäkokonaisuuteen

Käytännöllinen suunnittelu pitää tilauksen, lähetyksen ja seurantatapahtuman erillisinä tietueina. Yksi tilaus voi tuottaa useita paketteja, ja jokaisella paketilla voi olla oma seurantahistoriansa. Asiakkaalle näkyvä tilaustila pitäisi johtaa näistä lähetystietueista sen sijaan, että ne korvattaisiin.

1. Tilaus on valmis toimitettavaksi. Myymälä tai tilaustenhallintajärjestelmä lähettää tarvittavat toimitustiedot vastuulliselle varastolle.
2. Lähetysprosessi luo lähetyksen. Sovellus tallentaa palautetun lähetystunnisteen, seurantanumeron, kuljetusyhtiön, palvelun ja osoitekortin viitteen.
3. Varasto suorittaa luovutuksen. Varaston vahvistus ja kuljetusyhtiön vastaanotto säilyvät toisistaan erotettavina tapahtumina.
4. Seurantaprosessi alkaa. Sovellus rekisteröi tai lähettää seurantanumeron valitun integraation edellyttämällä tavalla.
5. Seurantapäivitykset saavuttavat sovelluksesi. Webhookit, kyselyt tai tuettu yhdistelmä syöttää tietoja lähetystietueeseen.
6. Liiketoimintasäännöt päättävät seuraavan toimenpiteen. Järjestelmäsi päivittää asiakkaalle näkyvän tilan, luo operatiivisen tehtävän tai lähettää viestin, kun asiaankuuluvat ehdot täyttyvät.

Esimerkiksi kolmannen osapuolen toimitusvarastoa käyttävä kauppias saattaa tarvita omassa ohjelmistossaan vain vaiheet neljästä kuuteen. Varasto vastaa jo lähetysten luomisesta. Omaansa varastoa käyttävä kauppias saattaa tarvita koko työnkulun.

Määritä yksi vastuuhenkilö jokaiselle jatkotoimelle

Jos molemmat integraatiot toimittavat seurantapäivityksiä, määritä, mikä järjestelmä hallitsee asiakasilmoituksia ja myymälässä näkyvää lähetyksen tilaa. Muussa tapauksessa asiakkaat voivat saada päällekkäisiä viestejä tai nähdä ristiriitaisia toimitustiloja.

Voit säilyttää toissijaiset tiedot tutkimista varten estämättä kuitenkaan jokaista lähdettä käynnistämästä sähköpostia. Säilytä alkuperäinen kuljetusyhtiön tapahtuma sisäisen tilakartoituksesi rinnalla, jotta tukihenkilöstö ymmärtää, miksi järjestelmä luokitteli lähetyksen tietyllä tavalla.

Vertaa operatiivista sopivuutta, älä ominaisuusmerkintöjä

Varmista käyttämiesi kuljetusyhtiöiden ja palvelujen tuki

Kuljetusyhtiön tuki ei ole yksi kyllä tai ei -kysymys. Palvelu voi tukea kuljetusyhtiön seurantaa tukematta kuitenkaan kyseisen yhtiön osoitekorttien luomista. Osoitekorttien luominen voi myös riippua lähtömaasta, kuljetusyhtiötilin asetuksista tai palvelun kelpoisuudesta.

Muodosta testilista todellisten toimitusreittiesi perusteella. Sisällytä kotimaan paketit, kansainväliset lähetykset ja kaikki kuljetuskumppaneiden väliset luovutukset. Vahvista kunkin osalta tarvittava toiminto: lähetyksen luominen, seuranta tai molemmat. Laaja kattavuusväite on vähemmän hyödyllinen kuin niiden palvelujen onnistunut testaaminen, joihin liiketoimintasi luottaa.

Tarkastele tapahtumien merkitystä ja tietojen täydellisyyttä

Testaa seurannan osalta, mitä tapahtuu ennen ensimmäistä skannausta, toimituspoikkeaman aikana, epäonnistuneen toimitusyrityksen jälkeen ja toimituksen yhteydessä. Tarkista, sisältävätkö aikaleimat aikavyöhyketiedot ja ovatko kuljetusyhtiön alkuperäiset kuvaukset edelleen saatavilla.

Älä tulkitse normalisoitua tilaa lupaukseksi siitä, että tiedot ovat samanlaisia kaikilla kuljetusyhtiöillä. Arvioidut toimituspäivät, sijaintitiedot ja toimitustodisteet voivat riippua kuljetusyhtiöstä ja lähetyksestä. Päätä, miten käyttöliittymäsi toimii, kun kyseiset kentät puuttuvat.

Tarkista vikatilanteista palautuminen molemmilla puolilla

Lähetysten osalta lähetyksen luomisen aikakatkaisu vaatii erityistä huomiota: pyyntö on saattanut onnistua, vaikka sovelluksesi ei vastaanottanut vastausta. Varmista palveluntarjoajan tukemat päällekkäisyyksien estämis- ja täsmäytysmekanismit ennen kuin yrität uudelleen sokeasti.

Testaa seurannan osalta päällekkäiset ilmoitukset, viivästyneet tapahtumat, epäonnistunut webhook-toimitus ja tilapäiset päätepistekatkokset. Vahvista todennus, uudelleenyritysten toiminta ja palautusvaihtoehdot asiaankuuluvasta dokumentaatiosta. Suunnittele tapahtumien käsittely niin, ettei päivityksen toistaminen lähetä samaa asiakasilmoitusta uudelleen.

Vertaa kokonaiskäyttökustannuksia olettamatta tiettyä hinnoittelumallia

Erota API-maksut postimaksuista ja kuljetusyhtiötilin maksuista. Lähetys- ja seurantapalvelut voivat käyttää erilaisia laskutusyksiköitä, ja yhdistetty alusta voi paketoida ominaisuudet eri tavoin. Pyydä tarjous tai tarkista sovellettava suunnitelma juuri sille työnkululle, jota aiot käyttää.

Kysy, miten laskutettava käyttö määritellään, lasketaanko epäonnistuneet pyynnöt mukaan, miten toistuvat seurantalähetykset käsitellään ja mitä tapahtuu käytön ylittäessä sallitun määrän. Ota mukaan tekninen ylläpito, tukityö ja kahden integraation yhdenmukaisuuden ylläpitämisen kustannukset. Ilman määriteltyä lähetysvalikoimaa ja ajantasaisia kaupallisia ehtoja olisi harhaanjohtavaa todeta jokin kategoria halvemmaksi.

Tarkista tietoturva ja tietojen säilytys

Lähetysintegraatiot voivat käsitellä vastaanottajien osoitteita ja tullitietoja. Seurannan integraatiot voivat myös käsitellä lähetystunnisteita ja niihin liittyviä asiakastietoja. Vahvista, mitkä kentät ovat pakollisia, rajoita tunnistetiedot vain tarvittaviin käyttöoikeuksiin ja pidä salaisuudet poissa selaimen puoleisesta koodista.

Tarkista säilytys-, poisto- ja käyttöoikeusasetukset liiketoimintavaatimuksiasi vasten. Kätevän integraation ei pitäisi edellyttää sellaisten asiakastietojen lähettämistä, joita työnkulku ei tarvitse.

Käytännöllinen validointisuunnitelma ennen sitoutumista

Toteuta konseptitodistus edustavilla lähetyksillä sen sijaan, että käyttäisit vain pikaoppaan onnistunutta esimerkkiä. Sovi hyväksymiskriteereistä operatiivisen henkilöstön, teknisen tiimin ja asiakastuen kanssa.

• Lähetys: tuota tarvittavat osoitekorttimuodot ja varmista, että varaston laitteet voivat käyttää niitä.
• Tilausten kartoitus: testaa jaetut lähetykset, useat paketit ja korvaavat lähetykset menettämättä alkuperäistä historiaa.
• Seuranta: tarkista liiketoiminnallesi tärkeiden kuljetusyhtiöiden ja reittien todelliset tapahtumasarjat.
• Poikkeamat: varmista, että toimenpiteitä edellyttävä toimitusongelma saavuttaa oikean tiimin ilman, että jokaista epätavallista skannausta käsitellään automaattisesti virheenä.
• Palautuminen: keskeytä pyyntö tai webhook-päätepiste ja osoita, miten sovellus täsmäyttää puuttuvat tiedot.
• Viestintä: varmista, että vain nimetty järjestelmä lähettää kunkin asiakasilmoituksen.
• Kaupallinen sopivuus: arvioi maksut odotetun käytön ja palveluntarjoajan vahvistamien laskutusmääritelmien perusteella.

Päätössääntö: hanki ensin puuttuva ominaisuus. Jos lähettäminen toimii jo, arvioi seurannan integraatiota rakentamatta toimituksia uudelleen. Jos osoitekorttien luominen puuttuu, ratkaise lähetyksen toteutus ensin. Jos sovelluksesi hallitsee koko lähetyksen elinkaarta, validoi molemmat ominaisuudet ja päätä, onko yhdistetty vai erillinen arkkitehtuuri tiimillesi helpompi ylläpitää.

Usein kysytyt kysymykset

Sisältääkö shipping API aina seurannan?

Ei. Jotkin palvelut sisältävät molemmat ominaisuudet, kun taas toiset tarjoavat ne erillisten päätepisteiden, tuotteiden tai suunnitelmien kautta. Vaikka seuranta sisältyisi palveluun, tarkista sen tapahtumien yksityiskohtaisuus, päivitysten toimitustapa, kuljetusyhtiöiden tuki ja käyttöehdot ennen kuin käsittelet sitä ostoksen jälkeisen seurannan ratkaisuna.

Voinko seurata paketteja, joiden osoitekortit toimituskumppani loi?

Mahdollisesti kyllä. Sovelluksesi tarvitsee seurannan integraation edellyttämät tunnisteet, yleensä seurantanumeron ja tarvittaessa kuljetusyhtiön tunnisteen tai muita vahvistustietoja. Vahvista kumppanin kuljetusyhtiöiden tuki ja varmista, että seurantanumerot siirtyvät luotettavasti järjestelmääsi.

Saako tracking API kuljetusyhtiön skannaukset tapahtumaan nopeammin?

Se ei voi luoda fyysisiä kuljetusyhtiön skannauksia. Se voi auttaa sovellustasi hakemaan, järjestämään ja jakelemaan seurantatietolähteiden saataville asettamia tietoja. Arvioi päivitysten toiminta todellisten lähetysten avulla sen sijaan, että olettaisit API:n takaavan välittömän näkyvyyden jokaiseen liikkeeseen.

Tarvitsenko kaksi API-palveluntarjoajaa käyttääkseni molempia ominaisuuksia?

Et. Tarvitset molemmat toiminnot, mutta et välttämättä kahta toimittajaa. Käytä yhtä palveluntarjoajaa, kun se täyttää lähetys- ja seurantavaatimuksesi. Erota ne toisistaan, kun se säilyttää toimivan työnkulun tai täyttää tietyn vaatimuksen, jota yhdistetty vaihtoehto ei täytä.

Voiko tracking API korvata tilaustenhallintajärjestelmän?

Ei. Seurantatiedot ovat tilaustenhallinnan syöte, eivät korvike varaston kohdistamiselle, toimituspäätöksille, maksujen käsittelylle tai tilaustietueille. Sovelluksesi on edelleen yhdistettävä jokainen lähetys oikeaan tilaukseen ja päätettävä, miten lähetystapahtumat vaikuttavat liiketoiminnan työnkulkuihin.

Lähteet

• FedEx Ship API -dokumentaatio — viite lähetysten luomiseen, osoitekortteihin ja lähetysprosessin vaatimuksiin.
• FedEx tracking API -dokumentaatio — viite seurantapyyntöihin ja lähetyksen tilatietoihin.
• 17TRACK Tracking API — virallinen tuoteviite seurantaintegraatioiden kategoriaan.
• 17TRACK API -dokumentaatio — viite seurannan rekisteröintiin, seurantatietoihin ja push-ilmoitusintegraatioon.