Calculadora de pagamento por horas

Uma tarifa horária negativa é rejeitada com um erro claro invalid_input, porque um salário negativo não descreve um cálculo válido de bruto.

Entradas: horas trabalhadas, tarifa horária, multiplicador extra e limiar opcional

Contagens de horas negativas, multiplicadores negativos e limiares negativos também são rejeitados para que uma inversão acidental de sinal falhe alto em vez de inventar negativos absurdos num recibo. Toda a validação ocorre antes de qualquer matemática monetária, assim pedidos ruins nunca produzem linhas de pagamento pela metade. Você envia o total de horas, não uma divisão prévia de regulares versus extra: a calculadora faz essa divisão a partir do limiar que você escolheu ou do valor padrão de quarenta. Envie um corpo JSON com três campos obrigatórios e um corte opcional. hours_worked é o tempo total no relógio da janela de pagamento, como número finito não negativo ou string numérica; aceitam-se os aliases hours, hrs, total_hours e weekly_hours quando o seu cliente já nomeia o campo de outro jeito. hourly_rate é o salário base por hora como número finito não negativo ou string numérica; os aliases rate, wage, hourly e pay_rate mapeiam para o mesmo valor para que montadores de formulário conservem rótulos familiares. overtime_multiplier é o adicional expresso como múltiplo da tarifa base —por exemplo 1.5 significa hora e meia e 2 significa hora dupla—, não um percentual do salário; os aliases multiplier, ot_multiplier, ot_rate e premium mapeiam para o mesmo campo. overtime_threshold é opcional e vale quarenta horas por omissão, o teto semanal comum de tempo normal; os aliases threshold, ot_threshold, regular_limit e cutoff deixam você nomear uma regra diária de oito horas ou um teto semanal local sem mudar o resto do contrato. Tarifas horárias negativas falham a validação com invalid_input porque não descrevem um holerite normal. Tarifas, totais de horas, multiplicadores ou limiares extremamente grandes são limitados para que a matemática do Worker isolate permaneça limitada. Faltar qualquer campo obrigatório falha com invalid_input nomeando a chave ausente.

Como as horas extras, o pagamento extra e o bruto são calculados

As fórmulas centrais são as que as pessoas já usam à mão num timesheet, só que a divisão das horas extras é feita para você. O bruto é a soma dessas duas linhas. Os produtos intermediários usam aritmética de ponto flutuante ordinária; depois cada campo monetário é arredondado half-up a duas casas decimais para que os resultados pareçam moeda num holerite e não frações binárias longas. Exemplo: uma tarifa de vinte, quarenta e oito horas trabalhadas, um multiplicador de 1.5 e o limiar padrão de quarenta produz quarenta horas regulares, oito extras, oitocentos de pagamento regular, duzentos e quarenta de extra, uma tarifa extra efetiva de trinta e um bruto de mil e quarenta após o arredondamento. Se as horas ficam no limiar ou abaixo, as horas extras e o pagamento extra são zero e o bruto é simplesmente tarifa vezes horas. A mesma matemática para toda jurisdição é um recorte de produto intencional: tabelas legais, regras do sétimo dia e retenção fiscal seriam intenções de busca e contratos distintos. As horas regulares equivalem ao menor entre hours_worked e overtime_threshold. As horas extras equivalem ao maior entre hours_worked menos o limiar e zero. O pagamento regular é igual a hourly_rate vezes as horas regulares. O pagamento extra é igual a hourly_rate vezes overtime_multiplier vezes as horas extras. A resposta também devolve ot_hourly_rate como hourly_rate vezes o multiplicador para que as interfaces mostrem o salário efetivo de extra ao lado da tarifa base. A resposta ecoa a tarifa horária normalizada, hours_worked, overtime_threshold e overtime_multiplier, e então devolve horas regulares, horas extras, ot_hourly_rate, regular_pay, overtime_pay e gross_pay, mais currency_decimals igual a dois e method igual a hours_pay_gross para ramificação estável do cliente. Entradas idênticas sempre produzem JSON idêntico porque o caminho é aritmética pura sem rede, sem semente aleatória e sem relógio de parede.

Uso da API, preços, fluxos de trabalho e limites práticos

Use a API pré-paga quando um bot de RH, um painel de freelancing, um portal de pessoal ou um auxiliar de timesheet precisar de um contrato KIT estável a US$ 0,002 por item bem-sucedido; falhas de validação nunca consomem saldo depois que o motor rejeita o pedido. Combine este endpoint com ferramentas de imposto ou dedução só se você já conhece à parte as regras de líquido: esta capacidade não retém impostos, não aplica benefícios nem converte moedas. Autores que enviam SDK podem mapear regular_pay, overtime_pay e gross_pay diretamente em interfaces de holerite e mensagens de estimativa. Quando citar o preço da API no texto do produto, use o marcador de catálogo US$ 0,002 para que as páginas publicadas permaneçam alinhadas com o piso de preço ao vivo.