Overtime and regular pay calculator

Inputs: hourly rate, regular hours, overtime hours, and multiplier

Negative hour counts and negative multipliers are also rejected so accidental sign flips fail loudly instead of inventing absurd negatives on a payslip. All validation happens before any money math, so bad requests never produce half-filled pay rows that a UI might misread as success. You already decide which hours are regular versus overtime under your local rules or company policy; this calculator multiplies what you send rather than inventing a forty-hour week threshold or a daily overtime table. That separation keeps the search intent clear: people who already know their regular and OT split want the money lines, not a jurisdiction engine. Send a JSON body with four required fields that describe a single pay period. Hourly rate is the base wage per hour as a non-negative finite number or numeric string; aliases rate, wage, hourly, and pay_rate are accepted when your client already names the field differently. Regular hours are the straight-time hours paid at that base rate; aliases hours, straight_hours, regular, and straight_time map to the same value so form builders can keep familiar labels without rewriting payloads. Overtime hours are the premium hours for the same pay period; aliases ot_hours, overtime, and ot are supported so timesheet exports can map columns with minimal glue code. Overtime multiplier is the premium expressed as a multiple of the base rate—for example one point five means time-and-a-half and two means double time—not a percentage of the wage; aliases multiplier, ot_multiplier, ot_rate, and premium map to the same field. Negative hourly rates fail validation with invalid_input because they do not describe a normal paycheck. Extremely large rates, hour totals, or multipliers are capped so Worker isolate math stays bounded and predictable under load. Missing any of the four fields fails with invalid_input naming the missing key. Document the four fields once in your SDK and reuse the same shapes for demos, bots, and integration tests.

How regular pay, overtime pay, and gross pay are computed

The response also returns ot_hourly_rate as hourly rate times the multiplier so UIs can show the effective overtime wage next to the base rate without recomputing it client-side. The response echoes the normalized hourly rate, regular hours, overtime hours, and overtime multiplier, then returns ot_hourly_rate, regular_pay, overtime_pay, and gross_pay, plus currency_decimals equal to two and method equal to overtime_gross for stable client branching across versions. Use regular_pay alone when you only need the straight-time line; use overtime_pay when a report needs the premium line; use gross_pay when a contractor invoice or weekly estimate needs the combined amount.

API usage, pricing, workflows, and practical limits

Use the prepaid API when an HR bot, freelancing dashboard, staffing portal, or timesheet helper needs a stable KIT contract at $0.002 per successful item; validation failures never consume balance after the engine rejects the request. Pair this endpoint with tax or deduction tools only if you already know net-pay rules separately—this capability does not withhold taxes, apply benefits, convert currencies, or invent shift differentials. Authors shipping SDKs can map regular_pay, overtime_pay, and gross_pay directly into payslip UIs, estimate messages, and export columns without reinventing half-up money rounding. When you cite the API price in product copy, use the catalog placeholder $0.002 so published pages stay aligned with the live price floor after catalog updates.