API
Intégrateur Boxtal API : du devis au colis suivi, sans décision invisible
Dawap relie Boxtal à votre e-commerce, OMS, WMS, ERP ou marketplace lorsque le choix transport ne peut plus tenir dans un plugin : adresses et colis à qualifier, offres à comparer, règles de coût et de promesse à arbitrer, shipping order à créer, documents à rattacher et tracking à rendre lisible au support. Le middleware conserve la raison du choix, l’identité de l’expédition et la preuve de chaque reprise.
- Offre retenue avec sa règle
- Label rattaché sans recréation aveugle
- Tracking relu par le support
APIs, données et infrastructures que nos projets savent connecter
Du besoin métier au run mesurable
01
Contrat
versionné
02
Sécurité
explicite
03
Reprise
testée
04
Supervision
actionnable
Réponse immédiate
Boxtal API compare des offres multi-transporteurs ; une intégration fiable doit encore prouver le service commandé et le colis réellement suivi.
Dawap construit le middleware qui contrôle les données d’adresse et de colis, applique votre règle de choix, conserve le shippingOfferCode retenu, crée ou retrouve le shipping order, rattache les documents d’expédition puis traduit le tracking vers l’OMS, le support et le client. Chaque timeout ou événement désordonné est repris à partir de l’état relu, pas d’une simple réponse HTTP.
- Privilégier l’API v3 JSON pour un nouveau flux ; borner la v1 XML aux contraintes legacy vérifiées.
- Séparer devis, commande ou annulation d’expédition, documents, tracking par webhook et repositories.
- Conserver les identifiants commande, colis, offre, shipping order, document et tracking sous une corrélation commune.
- Relire l’état Boxtal avant toute recréation lorsque la réponse ou la livraison du document reste ambiguë.
Shipping decision passport · scénario illustratif
Trois offres remontent. Une seule doit voyager avec la bonne raison.
La commande, les offres, montants, transporteurs et identifiants ci-dessous sont fictifs. Ce passeport montre comment garder choix, ordre, document et tracking sous une même preuve.
01 · Comparaison
Offres admissibles au devis témoin
AX
Transporteur fictifAtlas Standard
- Coût
- 13,90 €
- Promesse
- J+3
- Mode
- Domicile
NV
Transporteur fictifNova Priority
- Coût
- 15,40 €
- Promesse
- J+2
- Mode
- Domicile
RL
Transporteur fictifRelais Local
- Coût
- 10,80 €
- Promesse
- J+4
- Mode
- Relais
Règle fictive v9
Domicile obligatoire · promesse ≤ J+2 · coût ≤ 18 € · collecte Lyon · fallback validé par la logistique.
02 · Passeport
L’ordre conserve son offre et son colis
SHIPPING ORDER FICTIFSO-74…K9
DOCUMENT REÇU- Référence métier
- CMD-8041 / P-01
- shippingOfferCode
- OFR…NV42
- Document
- LBL…8C1 · PDF
- trackingId
- TRK…392
VerdictUn ordre · un document · une corrélation
- 09:41:11Devis reçu3 offres comparées
- +18 msRègle v9Nova retenue · 92/100
- +640 msOrder acceptéSO-74…K9 consigné
- +2 minDocument liéévénement DOCUMENT
- J+1Tracking reluétat client réconcilié
Premier lot recommandé
Un canal, un entrepôt, un type de colis et trois offres.
Apportez le colis qui reçoit deux labels, perd son suivi ou change silencieusement de service. Le cadrage rend éligibilité, choix, ordre, document et reprise lisibles avant d’ouvrir d’autres pays.
Quand le tarif paraît suffire
Le devis le moins cher peut produire le mauvais service, un second label ou un suivi impossible à expliquer.
Boxtal agrège les possibilités de transport. Votre SI doit encore décider quelle offre est éligible, prouver celle qui a été commandée et reprendre les états asynchrones sans confondre expédition et commande.
01
Éligibilité
Une offre remonte, mais ne respecte pas la promesse client
Coût, délai, mode, origine, destination, dimensions, assurance et règle de canal sont comparés avant de retenir le shippingOfferCode.
02
Unicité
Un timeout déclenche une seconde commande d’expédition
Le connecteur conserve commande, colis, offre, tentative et état relu. Il ne recrée pas un label tant que le premier effet reste ambigu.
03
Chronologie
Le document et le tracking arrivent après la réponse initiale
Shipping order, document et événement de suivi sont des étapes séparées. Le support voit ce qui manque et quelle reprise est autorisée.
Contrats d’un shipping multi-transporteurs
Six contrats empêchent le comparateur de devenir une boîte noire logistique.
L’agrégateur expose des offres et des opérations shipping. La responsabilité de la donnée colis, de la règle de choix et de la preuve client reste partagée entre vos outils.
Adresse et colis sont qualifiés avant le devis
Pays, code postal, poids, dimensions, contenu, origine et contraintes douanières sont normalisés avec un refus explicite lorsqu’une donnée critique manque.
Le tarif ne décide jamais seul
Coût complet, délai, mode, promesse, valeur, canal, entrepôt et disponibilité produisent une décision versionnée avec fallback autorisé.
L’offre retenue reste liée au shipping order
La corrélation conserve shippingOfferCode, commande, colis, tentative et résultat afin de retrouver un effet ambigu avant toute nouvelle création.
Le label possède son propre état de réception
Le système distingue ordre accepté, document disponible, téléchargement, archivage et réimpression ; une absence momentanée ne vaut pas échec définitif.
Le statut brut survit à la normalisation
Tracking et événements conservent valeur fournisseur, horodatage et corrélation avant de produire l’état client, l’action support ou l’alerte.
Annulation et reprise vérifient l’état courant
Chaque geste contrôle la compatibilité de l’état et l’effet déjà produit, puis journalise décision, refus ou escalade au bon owner.
Méthode offre–colis–preuve
Signer la règle de choix avant d’autoriser la création du shipping order.
Dawap part du colis qui coûte trop cher, reçoit deux labels ou disparaît du suivi. Logistique, e-commerce, support et IT nomment les données d’entrée, les offres admissibles, le fallback, l’identité du colis, les états asynchrones et la preuve de clôture avant d’ouvrir le flux.
Expliquer l’offre
Retrouver les critères, la version de règle et le service qui ont produit le choix.
Retrouver l’ordre
Relire l’état d’un shipping order ambigu avant toute nouvelle création.
Rattacher le document
Conserver label, colis, format et événement sous la même corrélation.
Reprendre le suivi
Réordonner ou compenser les événements sans perdre le statut brut.
Premier lot Boxtal
Faire voyager un colis difficile avant d’ouvrir tous les canaux.
On choisit un canal, un entrepôt, un type de colis et trois offres représentatives. Le lot est accepté lorsque le service retenu peut être expliqué, que le même shipping order est retrouvé après timeout et que document comme tracking reviennent au bon dossier.
1 canal
1 entrepôt
1 type de colis
3 offres
5 contre-tests
Sorties attendues
Carte e-commerce–OMS–WMS–ERP–Boxtal–support avec source de vérité et droit d’écriture pour chaque état.
Contrat adresse, colis, contenu, service, option, coût, délai, offre, shipping order, document et tracking.
Matrice d’éligibilité des trois offres avec critères bloquants, score, fallback autorisé et owner de la règle.
Cinq contre-tests : adresse invalide, offre devenue indisponible, timeout après création, document retardé et tracking désordonné.
Journal expurgé reliant commande, parcel ref, shippingOfferCode, shipping order, document, trackingId, tentative et verdict.
Recette logistique–service client–IT, balance attendu–créé–documenté–suivi, alertes et runbook de reprise.
Recette Boxtal–SI
Trois situations qui doivent converger vers un passeport d’expédition défendable.
Ces scénarios et leurs valeurs sont illustratifs. Ils doivent être rejoués sur votre compte, vos transporteurs, services, pays et règles. Aucun projet public ci-dessous n’est présenté comme une intégration Boxtal livrée.
Le service choisi au checkout n’est plus admissible à la préparation.
- Scénario terrain
- Le poids final ou l’adresse corrigée sort le colis des limites de l’offre conservée. Commander malgré tout créerait un refus tardif ou un service différent.
- Architecture
- Snapshot des données de devis, matrice d’éligibilité versionnée, revalidation avant order et fallback explicitement autorisé.
- Livrable
- Fixture avant–après, trace du shippingOfferCode, écart de règle et décision logistique.
- Décision
- Recalculer et demander confirmation, ou bloquer le colis ; ne pas choisir silencieusement l’offre suivante.
- Résultat vérifiable
- Le service commandé respecte la décision actuelle et tout changement de promesse reste visible.
Le client ne sait pas si le shipping order a été créé.
- Scénario terrain
- La réponse se perd après l’envoi. Un retry immédiat pourrait générer un second ordre ou un second label pour le même colis.
- Architecture
- Clé métier colis–commande, journal de tentative, recherche d’état Boxtal, verrou par effet et file d’ambiguïté.
- Livrable
- Deux fixtures réseau, balance d’ordres, trace de relecture et commande de reprise ciblée.
- Décision
- Retrouver ou faire arbitrer l’ordre existant avant d’autoriser toute recréation.
- Résultat vérifiable
- Un colis conserve un seul ordre accepté et une raison documentée si une nouvelle création devient nécessaire.
Un événement plus ancien arrive après une étape récente.
- Scénario terrain
- Le webhook contient un statut valide mais son horodatage précède l’état déjà publié au support. L’appliquer ferait régresser la chronologie client.
- Architecture
- Inbox dédupliquée, statut brut, date fournisseur séparée de la réception, règle de transition et réconciliation périodique.
- Livrable
- Séquence permutée, mapping des statuts, preuve de non-régression, métrique de retard et runbook.
- Décision
- Conserver l’événement dans l’audit sans remplacer l’état métier plus récent.
- Résultat vérifiable
- La chronologie reste monotone côté client et exhaustive côté support.
Boxtal, WMS/OMS ou transporteur direct ?
Le bon owner dépend de l’objet qui doit faire foi.
Cette offre possède l’agrégation shipping Boxtal. Les pages voisines gardent la préparation, l’architecture multi-transporteurs et les contrats spécifiques à chaque opérateur.
Le besoin part des offres, shipping orders, documents ou événements Boxtal
Cette page cadre le connecteur produit, le choix multi-transporteurs, les identifiants, la reprise et le run Boxtal.
Le problème principal est la commande à préparer ou l’état de stock
Le hub WMS/OMS possède allocation, vague, picking, colisage, stock disponible et ordre de préparation.
La décision compare agrégateur, transporteurs directs et architecture cible
Le hub shipping porte la stratégie multi-carrier, la normalisation transverse et le choix de raccordement.
Frontières de responsabilité
Orienter chaque vérité vers la page qui peut réellement la défendre.
Boxtal possède l’expédition agrégée. L’OMS/WMS garde la préparation, l’e-commerce la promesse de vente et l’ERP les coûts et documents de gestion.
Pour Art’Sacs, activité reprise depuis par France Appro, Dawap a relié Aster et PrestaShop afin de transformer le catalogue fournisseur, synchroniser les quantités, enrichir les fiches et préparer les commandes dropshipping. Les tâches, états et erreurs donnent aux équipes un flux pilotable plutôt qu’une synchronisation opaque.
Questions d’achat
Questions fréquentes avant une intégration Boxtal API
Réponses sur API v3, devis, shipping orders, labels, tracking, choix transporteur et premier lot.
01Quelle version de l’API Boxtal faut-il utiliser ?
Pour un nouveau flux, on qualifie d’abord l’API v3 JSON présentée par le portail développeur. Une v1 XML existante est traitée comme une contrainte legacy dont la migration, les endpoints et les formats doivent être vérifiés.
02Que peut automatiser une intégration Boxtal API ?
Elle peut relier la qualification du colis, les offres, la règle de choix, le shipping order, les documents d’expédition, le tracking et les exceptions à votre e-commerce, OMS, WMS, ERP, marketplace ou support.
03Comment choisir une offre Boxtal sans regarder seulement le tarif ?
On formalise coût complet, délai, mode, origine, destination, poids, dimensions, valeur, canal, promesse et fallback. La version de cette règle et le shippingOfferCode retenu restent attachés au colis.
04Comment éviter deux labels après un timeout ?
Le connecteur conserve une clé métier stable, la tentative et les identifiants connus, puis relit l’état Boxtal avant toute recréation. Un résultat ambigu part en reprise contrôlée au lieu d’un retry aveugle.
05Comment synchroniser le tracking Boxtal ?
Les événements sont dédupliqués, conservés avec leur statut brut et leur horodatage, puis traduits vers une chronologie métier. Un événement ancien n’écrase pas automatiquement un état client plus récent.
06Quel premier lot Boxtal recommandez-vous ?
Un canal, un entrepôt, un type de colis et trois offres. On exerce adresse invalide, offre expirée, timeout après création, document retardé et tracking désordonné avant d’ajouter pays ou canaux.
Boxtal API · Devis · Expédition · Tracking
Votre prochain colis Boxtal peut-il prouver son offre, son ordre, son document et son suivi ?
Dawap peut cadrer ce colis témoin puis construire le middleware, la trace et le run qui protègent le choix transport jusque dans les réponses ambiguës et les événements désordonnés.
Auditer mon flux Boxtal