O problema das chaves de API que nunca expiram
Uma chave emitida anos atrás, nunca trocada e ainda válida hoje não é uma conveniência. É um risco que ninguém examina de verdade há anos.
O que a cobrança por produto erra sobre como as APIs são usadas
Abra o log de requisições de quase qualquer aplicação que use dados de localização e você não vai encontrar um único tipo de consulta rodando isoladamente. Um formulário de cadastro geocodifica um endereço, verifica o IP para uma correspondência aproximada de rede e marca o registro com um fuso horário, tudo nas mesmas poucas centenas de milissegundos. Esses não são três casos de uso separados que por acaso compartilham um provedor de API. São um único fluxo de trabalho que envolve três tipos de dados.
A cobrança por produto finge o contrário. Ela coloca a geocodificação em um plano, as consultas de IP em outro, e os dados de fuso horário ou altitude como complementos opcionais com tarifas próprias, como se uma empresa que precisa de um deles dificilmente fosse precisar dos outros. Na prática, o oposto é verdadeiro: precisar de um deles geralmente é sinal de que você precisa de pelo menos mais um. Um checkout de e-commerce que geocodifica um endereço de entrega quase certamente também quer saber em que fuso horário agendar uma janela de entrega. Uma verificação de fraude que analisa um endereço IP geralmente quer cruzá-lo com um endereço cadastrado.
Definimos o preço da My Geocode como um único produto com uma única tarifa. Todos os endpoints, geocodificação, consulta de IP, fuso horário, altitude, código postal, e todos os hosts de compatibilidade custam exatamente o mesmo por requisição. Não há uma tabela de preços separada para conciliar, nem um plano que adiciona dados de fuso horário só depois que você já pagou por um plano de geocodificação. Uma requisição é uma requisição, seja qual for o endpoint que ela atinge.
Isso não é só um conforto para o cliente. Reflete como o trabalho subjacente realmente acontece. Uma consulta a um endpoint não tem um custo de atendimento drasticamente diferente de uma consulta a outro, na escala em que a maioria das aplicações opera. Dividi-los em produtos separados com preços separados não acompanha uma diferença real no custo de responder à requisição. Acompanha quantos itens separados um provedor consegue colocar em uma fatura.
A cobrança por produto também torna mais difícil entender o seu próprio uso. Se a geocodificação é cobrada de um jeito e as consultas de IP de outro, estimar a conta do próximo mês significa acompanhar dois contadores em duas estruturas de tarifas e torcer para que a combinação de chamadas não mude de um jeito que altere o total de forma imprevisível. Uma tarifa fixa e unificada reduz essa estimativa a um único número: total de requisições vezes um preço. Qualquer pessoa montando o orçamento da sua integração consegue fazer essa conta nas costas de um envelope.
Há uma suposição mais profunda escondida na cobrança por produto que achamos simplesmente errada: a de que tipos diferentes de dados de localização atendem clientes diferentes. Na nossa experiência, eles atendem o mesmo cliente, em pontos diferentes da mesma requisição. Uma plataforma de logística, um fluxo de cadastro e um sistema antifraude juntam dados de geocodificação, IP e fuso horário em uma única decisão. Preços que fingem que esses são mercados separados obrigam os clientes a pagar a mais por um pacote que usam de forma desigual ou a lidar com vários fornecedores para evitar isso. Uma tarifa, uma lista de endpoints: essa é a resposta mais simples e mais honesta.