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.
Por que ambientes de sandbox deveriam ser gratuitos
Algumas APIs oferecem um ambiente de sandbox funcionalmente separado da produção: chaves diferentes, às vezes endpoints diferentes, ocasionalmente uma estrutura de preços própria ou limites próprios mais restritivos. A intenção é razoável: dar aos desenvolvedores um espaço seguro para testar sem mexer no uso real nem na cobrança real. Na prática, um sandbox que exige sua própria etapa de cadastro, sua própria chave ou sua própria etapa de upgrade pago adiciona atrito exatamente no momento em que um desenvolvedor está tentando decidir se a sua API vale algum atrito.
Nós não mantemos um sandbox separado. Testes e produção usam a mesma cota gratuita diária: 2.500 requisições por dia a partir de qualquer endereço sem chave, e mais 2.500 por dia quando você adiciona uma chave, contadas por rede. Não há um modo de teste separado com limites próprios para aprender nem um plano pago que coloque testes sérios atrás de uma compra. Tudo o que você usa durante a avaliação é exatamente o mesmo sistema em que você faz o deploy, com exatamente a mesma cota gratuita, antes de gastar um único euro.
Isso importa porque um sandbox que se comporta de forma um pouco diferente da produção está testando o sandbox, e não a sua integração. Se um sandbox separado usa dados de resposta simplificados ou falsos em vez do conjunto de dados real, você só descobre as peculiaridades dos dados do mundo real depois de entrar no ar, o que anula boa parte do que os testes deveriam detectar. Testar no sistema real, com dados reais, usando a cota gratuita real, significa que o que você aprende durante a avaliação é de fato verdadeiro para o que você vai rodar em produção.
Não colocar o acesso ao sandbox atrás de uma etapa paga separada tem um custo para nós: uma parte desse tráfego de testes gratuito nunca vai se converter em uma conta pagante, a mesma troca de qualquer nível gratuito generoso. Achamos que esse custo vale a pena, porque a alternativa empurra exatamente o incentivo errado para um desenvolvedor que está decidindo se vai construir com a sua API. Um modo de teste pago ou muito restrito pede que alguém se comprometa financeiramente antes de saber se o produto serve para o seu caso de uso. Um caminho de testes gratuito e totalmente funcional permite que essa decisão seja tomada pelos méritos, depois de realmente experimentar.
Nada disso significa que os testes não têm nenhum limite. As mesmas 2.500 requisições por dia que cobrem um uso leve em produção também cobrem os testes, e um teste de carga em grande escala nessa cota vai atingir o mesmo teto que uma pequena integração em produção atingiria. Isso é intencional. O nível gratuito é generoso o bastante para uma avaliação real, não infinito, e tratá-lo como o seu ambiente de testes permanente para um produto de alto volume é algo diferente de usá-lo para confirmar que uma integração funciona antes de passar para o uso pago.
Um sandbox deveria responder a uma pergunta com honestidade: isto funciona como eu espero, usando a coisa real? Cobrar por essa resposta, ou respondê-la com qualquer coisa que não seja a coisa real, anula o propósito de qualquer forma.