Calculateur de taux croisé

Ce que mesure un taux de change croisé et comment fonctionne la triangulation

Si les deux cotations s'expriment en unités de cette devise pour une unité de la base, une unité de la devise d'origine vaut un divisé par from_rate unités de la base, et ce montant en base achète to_rate divisé par from_rate unités de la devise de destination. Si les deux cotations s'expriment au contraire en unités de la base pour une unité de la devise — la convention de nombreux écrans dollar-par-euro et dollar-par-yen —, l'identité s'inverse : le taux croisé est from_rate divisé par to_rate.

Contrat d'entrée, conventions de cotation et champs de réponse

Les deux cours et le montant doivent être strictement supérieurs à zéro : une cotation nulle ou négative rendrait la paire implicite indéfinie ou inverserait l'économie d'un échange, et un montant non positif est rejeté pour le même domaine de cours. Associez les chiffres à votre propre flux en direct si vous avez besoin d'un mid horodaté ; ce point de terminaison calcule uniquement la paire implicite à partir des deux cours que vous détenez déjà. Envoyez par POST un corps JSON avec deux nombres finis obligatoires : from_rate, la cotation de la devise d'origine contre la base partagée, et to_rate, la cotation de la devise de destination contre cette même base. Envoyez éventuellement amount comme la quantité d'origine à convertir (valeur par défaut un), quote comme units_per_base ou base_per_unit (valeur par défaut units_per_base), et decimals comme un entier de zéro à douze (valeur par défaut six) pour contrôler l'arrondi half-up sur chaque champ numérique. Les champs manquants, les chaînes vides, les valeurs non finies, un jeton quote inconnu et des decimals non entiers hors de la plage autorisée échouent avec invalid_input et ne sont pas facturés. Des alias courants sont acceptés : source_rate, rate_from ou from_vs_base pour from_rate ; dest_rate, target_rate, rate_to ou to_vs_base pour to_rate ; qty ou quantity pour amount ; quote_mode ou convention pour quote. En cas de succès le corps renvoie les entrées renvoyées en écho, quote, cross_rate comme unités de destination pour une unité d'origine, inverse_rate comme le réciproque, converted comme amount multiplié par le taux croisé, base_value comme le montant d'origine exprimé dans la base, et formula. Exemple : from_rate 0.92, to_rate 150, amount 200, quote units_per_base produit un croisé près de 163 unités de destination par unité d'origine, car 150 divisé par 0.92 est l'identité yen-par-euro lorsque les deux jambes sont cotées par dollar.

Où une API de taux de change croisé justifie son existence

Les planificateurs de voyage et les itinéraires multi-pays utilisent un calculateur de taux de change croisé pour qu'un budget rédigé en euros puisse être réexprimé en yens, pesos ou livres à partir de deux cotations contre le dollar, sans attendre une paire dédiée qu'une carte d'embarquement ou une facture d'auberge n'imprime jamais. Les desks voyages d'entreprise et les outils de notes de frais ont besoin d'un oracle déterministe qui refuse une cotation nulle au lieu d'inventer une conversion creuse qu'une feuille défectueuse pourrait traiter comme une parité. Une validation en échec ne consomme pas de solde. Les générateurs d'examens et les séries d'économie ouverte demandent l'identité triangulaire dans les deux conventions de cotation ; figer l'arithmétique dans une petite API parse évite la dérive des tableurs dans le barème. Comme l'implémentation est parse pure de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans jetons de modèle et sans réseau sortant. Gardez les requêtes petites, figez dans les tests les champs arrondis cross_rate et converted, et vous obtenez des paires implicites reproductibles pour les devoirs, les greffons LMS et les workers en bordure, sans dresser un pipeline FX en direct ni confondre cette identité avec un taux réel de pouvoir d'achat.