Lineare Zoll

Geben Sie positive length, width und height in Zoll oder Zentimetern ein; jede fehlende, null, negative oder nicht numerische Seite wird als invalid_input abgelehnt, damit eine leere Messung nie als Freifahrt an der Größenlehre gilt. Die Prepaid-API berechnet $0.002 pro erfolgreichem Element, wenn Pack-Apps, Kofferseiten und Reiselisten dieselbe deterministische Linear-Summe von Servern und SDK brauchen.

Was lineare Zoll bedeuten und welche Seiten Sie messen

Senden Sie die Pflichtfelder length, width und height als JSON-Zahlen oder numerische Zeichenketten in einer gemeinsamen Einheit. Optionales unit akzeptiert in für Zoll, den Standard, oder cm für Zentimeter; die Aliasse units, measure_unit und dim_unit werden geachtet. Die Aliasse l, len und depth gehören zu length; w und breadth zu width; h und ht zu height. Optionales limit (Aliasse max_linear, max, airline_limit, max_inches) ist die lineare Zoll-Decke der Airline, zum Beispiel 45 für viele US-Kabinenstücke oder 62 für viele Aufgabegepäckstücke. Jede Abmessung, die keine streng positive endliche Zahl ist, scheitert mit invalid_input, weil eine Null- oder Negativseite kein physischer Koffer ist. Identische Eingaben erzeugen stets dasselbe JSON: Addition plus den exakten Zoll-Zentimeter-Faktor 2.54, ohne Netz, ohne Zufallsseed und ohne Wanduhr.

linear_inches, Seiten in zwei Einheiten und optionales Limit lesen

Bei gültiger Anfrage gibt die Antwort length, width, height und unit nach stabiler Rundung zurück, plus length_in, width_in und height_in, damit Zentimeter-Eingaben vor der Addition in Zoll sichtbar sind. Das Primärfeld linear_inches ist die Summe dieser drei Zoll-Seiten und die Zahl, die Sie mit der veröffentlichten Airline-Tafel vergleichen. Das Feld formula wiederholt, dass linear_inches gleich length_in plus width_in plus height_in ist, und method ist stets sum_dimensions_to_linear_inches, damit Clients auf einer stabilen Zeichenkette verzweigen. Wenn Sie limit liefern, enthält der Körper außerdem within_limit als Boolesch, remaining_inches als Restspielraum bei Bestehen und excess_inches als Überschreitung bei Scheitern. Diese drei Deckenfelder entfallen vollständig, wenn Sie keine Obergrenze senden, damit eine einfache Summe einfach bleibt. Nutzen Sie linear_inches allein für die Packtagsprüfung; nutzen Sie die in Zoll umgerechneten Seiten, wenn ein Käufer Zentimeter aus einem europäischen Datenblatt tippte; nutzen Sie die Limitfelder, wenn Kasse oder Reiseliste Bestanden oder Nicht bestanden neben der Tarifzahl zeigen muss. Fehlende Pflichtseiten, nicht endliche Werte und jede Abmessung, die keine positive Zahl ist, scheitern mit invalid_input und werden nicht berechnet. Dieser Endpunkt lädt keine Markenrichtlinien; Sie oder Ihr Produkt liefern das Zahlenlimit, das zum tatsächlich gekauften Ticket passt.

API-Nutzung, Preis, Packabläufe und praktische Grenzen

Nutzen Sie den kostenlosen Browser-Rechner am Packtag, beim Vergleich zweier Koffer im Laden oder in einer Schuldemo zur Einheitenumrechnung ohne Tabellenkalkulation. Bei mehreren Stücken rufen Sie einmal je Gepäckstück auf, damit jedes nach seiner eigenen Kabinen- oder Frachtklasse beurteilt wird. Senden Sie einen JSON-Körper mit length, width, height, optionalem unit und optionalem limit (oder den dokumentierten Aliassen). Nutzen Sie die Prepaid-API, wenn ein Reiseportal, Gebührenschätzer, eine Kofferseite oder eine Pack-App einen stabilen Vertrag unter KIT-Saldo zu $0.002 pro erfolgreichem Element braucht; Validierungsfehler verbrauchen nie Saldo. SDK-Autoren können linear_inches, within_limit, remaining_inches und excess_inches in eine kleine Tabelle neben den drei Seiten legen: dieselbe Form, die Reisende auf den Größentafeln am Schalter sehen.