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.
Contra cobrar a mais por métodos básicos de autenticação
A autenticação é uma das partes mais banais de usar uma API, e é justamente o tipo de detalhe banal que acaba preso atrás de um plano de preços com mais frequência do que deveria. Alguns provedores reservam certos métodos de autenticação, HTTP Basic auth ou o padrão de Bearer token, para planos mais caros, enquanto um plano inferior só aceita um único formato de cabeçalho específico. A diferença de custo técnico entre validar um estilo de autenticação e outro é quase nula. O que muda é o quanto cada um é conveniente para o código existente de um determinado cliente, o que não tem nada a ver com quanto ele deveria pagar para usar a API.
Aceitamos uma chave como cabeçalho X-API-Key, como cabeçalho Authorization Bearer, via HTTP Basic auth com a chave como nome de usuário ou como parâmetro de consulta, em todos os hosts, sem custo extra para nenhum deles. Qualquer que seja o padrão que já se encaixa no seu código, qualquer biblioteca ou convenção interna que a sua equipe já usa para outras APIs, é muito provável que ele já seja aceito, sem precisar reestruturar nada só para seguir um formato específico que por acaso preferimos.
O raciocínio por trás de restringir métodos de autenticação por plano não tem a ver com custo. Tem a ver com diferenciar planos por diferenciar: encontrar recursos para reservar a um cliente que paga mais, mesmo recursos que não custam nada a mais para oferecer, simplesmente porque ter mais recursos bloqueados atrás de um plano superior faz esse plano parecer mais valioso em uma tabela comparativa. Métodos de autenticação são um alvo fácil para isso porque aceitar vários deles exige realmente pouco esforço do provedor e é realmente conveniente para o cliente, o que faz dessa restrição uma decisão puramente de monetização, e não uma baseada em qualquer diferença real de custo.
Achamos que esse tipo de restrição pune silenciosamente os desenvolvedores por uma decisão que não tem nada a ver com o valor que eles obtêm dos dados em si. Uma equipe cujas ferramentas usam Bearer tokens por padrão não deveria pagar mais do que uma equipe cujas ferramentas usam um cabeçalho personalizado, quando as duas fazem exatamente a mesma consulta e recebem exatamente a mesma resposta. O valor do produto é a resposta. O método de autenticação é encanamento, e encanamento não deveria ter um preço baseado em qual cano por acaso se encaixa na sua parede.
Há um princípio mais amplo aqui que vai além da autenticação: recursos que não custam nada a mais para o provedor oferecer não deveriam virar fronteiras artificiais entre planos só porque podem. Uma estrutura de planos baseada em diferenças reais de custo, como o volume de requisições, é defensável. Uma estrutura de planos inflada com conveniências de baixo custo reservadas a quem paga mais existe principalmente para fazer a página de preços parecer mais diferenciada do que o produto realmente é.