Uma chave para tudo é uma chave para o estrago todo

A maior parte das integrações tem uma chave só. Ela cria pedido, consulta saldo, lê histórico e mexe em configuração — e está na mesma variável de ambiente do servidor de produção, do de homologação e da máquina de quem está desenvolvendo.

Funciona até o dia em que não funciona. E aí o estrago é do tamanho do que aquela chave podia fazer.

Duas separações, uma mais urgente que a outra

Por ambiente é a mais urgente e a mais fácil.

Chave de produção não pode existir em ambiente de teste. Não é sobre desconfiar de ninguém: é que ambiente de teste tem log mais verboso, mais gente com acesso, mais ferramenta conectada e menos cuidado com o que vai para o repositório.

Se a chave é a mesma, um teste mal escrito gasta saldo real, e um vazamento em homologação é um vazamento em produção.

Por finalidade vem depois, e é o que limita o estrago.

Uma chave que só lê não pode gastar dinheiro. Se o processo que gera relatório usa uma chave de leitura, o vazamento dela expõe informação — não a carteira.

O princípio prático

Cada chave recebe o mínimo que a aplicação precisa para funcionar. Nem mais.

Na prática:

Uso	Precisa de
Painel interno que só mostra número	leitura
Processo que cria pedido	leitura e criação
Rotina de conciliação	leitura
Ferramenta de suporte	leitura, e nada mais

A pergunta que orienta: se esta chave vazar hoje, o que a pessoa consegue fazer? Se a resposta inclui gastar o seu saldo e o processo só precisava ler, o escopo está errado.

Uma chave por aplicação também

Além do ambiente e do escopo, vale separar por consumidor.

Duas aplicações compartilhando uma chave criam dois problemas. Você não sabe qual delas gerou determinado consumo. E revogar por causa de uma derruba a outra, no meio da madrugada, sem aviso.

Com chaves separadas, o incidente fica contido: você revoga uma, a outra segue.

Nomeie para o dia do incidente

Chave sem nome, ou com nome como "teste2", é inútil na hora que importa. Você olha a lista, vê cinco chaves, e não sabe qual pode revogar.

Um padrão que funciona: aplicação, ambiente, finalidade. conciliacao-producao-leitura. Quem olhar daqui a um ano entende.

E registre onde ela está sendo usada — mesmo que seja num documento simples. É essa lista que permite rotacionar sem esquecer nenhuma.

O que a separação de escopo não resolve

Chave de leitura ainda expõe dado. Se o seu histórico contém telefone de cliente, uma chave de leitura vazada é um incidente de privacidade, não de dinheiro.

Escopo reduz o estrago; não elimina. As outras camadas continuam necessárias: chave fora do repositório, fora do navegador, fora do log.

Comece pelo passo que rende mais

Se hoje existe uma chave só, a ordem que dá mais resultado com menos trabalho:

1. Separe produção de não-produção. Uma chave nova para teste, e a de produção sai de todo lugar que não seja produção.
2. Separe por aplicação. Uma por consumidor.
3. Reduza escopo onde for evidente — tudo que só lê passa a ser chave de leitura.

O primeiro passo sozinho já elimina a maior parte dos incidentes de chave que acontecem na prática, e leva uma tarde.

Para trocar chave sem derrubar integração, a ordem está em rotacionar chave de API sem downtime. E os lugares onde ela nunca pode estar, em onde a chave de API nunca pode estar.

Na AltiviaCloud cada chave é criada no painel e só aparece uma vez, porque a plataforma guarda apenas o hash. Ter uma por ambiente não muda a conta: a cobrança é por pedido, como está em preços.