Pouces linéaires

Saisissez des length, width et height positifs en pouces ou en centimètres ; tout côté manquant, nul, négatif ou non numérique est rejeté comme invalid_input afin qu'une mesure vide ne passe jamais pour un laissez-passer au gabarit. L'API prépayée facture $0.002 par élément réussi lorsque des applications d'emballage, des fiches valise et des listes de voyage ont besoin du même total linéaire déterministe depuis serveurs et SDK.

Définition des pouces linéaires et côtés à mesurer

Envoyez les champs obligatoires length, width et height comme nombres JSON ou chaînes numériques dans une seule unité commune. Le unit optionnel accepte in pour les pouces, valeur par défaut, ou cm pour les centimètres ; les alias units, measure_unit et dim_unit sont honorés. Les alias l, len et depth correspondent à length ; w et breadth à width ; h et ht à height. Le limit optionnel (alias max_linear, max, airline_limit, max_inches) est le plafond en pouces linéaires de la compagnie, par exemple 45 pour de nombreuses cabines aux États-Unis ou 62 pour de nombreuses pièces en soute. Toute dimension qui n'est pas un nombre fini strictement positif échoue avec invalid_input, car un côté nul ou négatif n'est pas une valise physique. Des entrées identiques produisent toujours le même JSON : addition plus le facteur exact pouce-centimètre de 2.54, sans réseau, sans graine aléatoire et sans horloge murale.

Lire linear_inches, les côtés en deux unités et le plafond optionnel

Si la requête est valide, la réponse renvoie length, width, height et unit après un arrondi stable, plus length_in, width_in et height_in afin que les saisies en centimètres apparaissent en pouces avant l'addition. Le champ principal linear_inches est la somme de ces trois côtés en pouces : c'est le chiffre que vous comparez au tableau publié de la compagnie. Le champ formula rappelle que linear_inches égale length_in plus width_in plus height_in, et method est toujours sum_dimensions_to_linear_inches pour que les clients branchent sur une chaîne stable. Lorsque vous fournissez limit, le corps inclut aussi within_limit comme booléen, remaining_inches comme marge si la valise passe, et excess_inches comme le dépassement si elle échoue. Ces trois champs de plafond sont entièrement omis si vous n'envoyez pas de limite, afin qu'un simple total reste un simple total. Utilisez linear_inches seul pour le contrôle du jour de l'emballage ; utilisez les côtés convertis en pouces lorsqu'un acheteur a saisi des centimètres d'une fiche européenne ; utilisez les champs de limite lorsqu'un paiement ou une liste de voyage doit afficher réussi ou échoué à côté du chiffre du tarif. Côtés obligatoires manquants, valeurs non finies et toute dimension qui n'est pas un nombre positif échouent avec invalid_input et ne sont pas facturés. Cet endpoint ne télécharge pas les politiques de marque ; vous ou votre produit fournissez la limite numérique qui correspond au billet réellement acheté.

Usage de l'API, tarif, flux d'emballage et limites pratiques

Utilisez le calculateur gratuit dans le navigateur le jour de l'emballage, pour comparer deux valises en magasin, ou pour une démonstration scolaire de conversion d'unités sans ouvrir un tableur. Pour un groupe à plusieurs bagages, appelez une fois par pièce afin que chacune soit jugée selon sa propre classe cabine ou soute. Envoyez un corps JSON avec length, width, height, unit optionnel et limit optionnel (ou les alias documentés). Utilisez l'API prépayée lorsqu'un portail voyage, un estimateur de frais, une fiche valise ou une application d'emballage a besoin d'un contrat stable sous solde KIT à $0.002 par élément réussi ; les échecs de validation ne consomment jamais le solde. Les auteurs de SDK peuvent mapper linear_inches, within_limit, remaining_inches et excess_inches dans un petit tableau à côté des trois côtés : la même forme que voient les voyageurs sur les panneaux de taille au comptoir.