Frequent-flyer miles earned

Pricing for successful API calls is the published base of $0.002 per item; failed validation is not charged.

How miles earned are calculated from fare, distance, rate, and status

Start from a published fare or a known segment distance and the earning language in your frequent-flyer program guide. In spend mode, base_amount is the eligible ticket fare in major currency units—often the base fare excluding taxes, or the amount the program states as revenue for accrual—and earning_rate is miles per currency unit, such as five miles per dollar on a co-brand card fare or one mile per euro on a basic revenue ticket. In distance mode, base_amount is the flown distance in statute miles or kilometers (use one unit consistently) and earning_rate is the accrual ratio as a decimal: one means one hundred percent of distance, zero point five means fifty percent, and one point five means a one-hundred-fifty percent class bonus already folded into the rate. The calculator multiplies base_amount by earning_rate to form base_miles. If you hold elite status or a co-brand bonus that advertises an extra percentage on top of base miles, put that figure in status_bonus_percent—for example fifty for plus fifty percent—so bonus_miles equals base_miles times the percent over one hundred and total_miles equals base_miles plus bonus_miles. Equivalently, total_miles equals base_amount times earning_rate times one plus status_bonus_percent over one hundred. Leaving status_bonus_percent out defaults it to zero so non-elite estimates stay honest. Negative amounts, missing required fields, non-finite numbers, and unknown mode strings fail with invalid_input so clients never see NaN or silent clamps. Identical inputs always produce identical JSON: no network chart fetch, no random jitter, and no clock dependence.

What you send and what you get back

Classic checks include a four-hundred currency fare at five miles per unit with a fifty percent status bonus, which yields two thousand base miles and three thousand total miles, or a two-thousand-five-hundred unit distance at one hundred percent accrual with a twenty-five percent status bonus, which yields two thousand five hundred base miles and three thousand one hundred twenty-five total. Wire the free browser form for one-off trip planning, then call the identical contract from scripts when you batch dozens of candidate fares against the same program rate table. Send base_amount and earning_rate as required finite numbers greater than or equal to zero. Optionally send status_bonus_percent as a non-negative finite number, and mode as the string spend or distance (aliases fare or revenue for spend, miles or km for distance). JSON strings that parse as numbers are accepted the same way as numeric literals. Missing base_amount or earning_rate, empty strings, NaN, Infinity, negative values, and invalid mode values all fail with invalid_input and are not charged. On success the response echoes the cleaned base_amount, earning_rate, status_bonus_percent, and mode; reports base_unit as currency or distance and rate_unit as miles_per_currency_unit or accrual_ratio; and returns base_miles, bonus_miles, total_miles, effective_multiplier equal to one plus the bonus percent over one hundred, and a human-readable formula string. Pricing for successful API calls is the published base of $0.002 per item; validation failures do not consume prepaid balance. Downstream tools can threshold on total_miles alone, store the full object for audit, or combine results with a separate cents-per-point valuation cap when deciding whether to burn or earn on a given itinerary.

Where frequent-flyer miles earned calculators show up in real work

Loyalty onboarding teams use the same JSON in demos and API sandboxes so offline worksheets stay aligned with production. Because this capability is a pure parse engine, API pricing is the published base of $0.002 per successful item and failed validation does not consume balance.