Sugestões

Atualmente, aplicações SaaS que desejam integrar seus clientes ao Asaas precisam, em muitos cenários, solicitar que o próprio cliente acesse o painel do Asaas, localize sua API Key e posteriormente copie e informe essa chave dentro da aplicação terceira.

Apesar de funcionar tecnicamente, esse fluxo gera alguns problemas importantes de experiência e segurança:

O cliente precisa localizar e manipular uma credencial sensível.
A API Key pode conceder mais acesso do que a aplicação realmente necessita.
O usuário pode copiar a chave para um local inseguro.
A aplicação parceira precisa armazenar uma credencial de longa duração.
O processo de conexão possui várias etapas e aumenta a dificuldade de onboarding.
Usuários menos técnicos podem ter dificuldade em realizar a configuração.
Não existe uma experiência simples de "Conectar com Asaas".
Revogar especificamente uma aplicação integrada pode ser mais difícil do que revogar uma autorização individual.

Plataformas de pagamento e serviços financeiros modernos utilizam fluxos de autorização semelhantes a OAuth/Connect, nos quais o usuário é redirecionado para o próprio ambiente do provedor, realiza login e autoriza explicitamente quais permissões deseja conceder à aplicação.

A aplicação terceira nunca recebe a senha do usuário.

Sugestão

Criar no Asaas um recurso chamado, por exemplo:

Asaas Connect

ou

Connect Auth

permitindo que aplicações devidamente cadastradas no Asaas utilizem um fluxo de autorização baseado em OAuth 2.0 Authorization Code, preferencialmente com suporte a PKCE, state, escopos de permissão e tokens revogáveis.

A experiência para o usuário seria:

1. Aplicação parceira

O sistema apresenta:

Conecte sua conta Asaas para receber pagamentos diretamente na sua conta.

[ Conectar com Asaas ]

2. Redirecionamento

Ao clicar no botão, o usuário é redirecionado para um domínio oficial do Asaas.

Exemplo conceitual:

https://auth.asaas.com/...

A URL poderia receber informações como:

client_id
redirect_uri
response_type=code
scope
state
code_challenge
code_challenge_method

3. Login realizado diretamente no Asaas

O usuário faz login exclusivamente no ambiente oficial do Asaas.

A aplicação parceira:

não recebe a senha;
não visualiza a senha;
não armazena a senha;
não precisa solicitar a API Key do cliente.

4. Tela de autorização

Após o login, o Asaas poderia apresentar algo semelhante a:

Navo deseja acessar sua conta Asaas

Permissões solicitadas:

✓ Consultar dados básicos da conta
✓ Criar e consultar clientes
✓ Criar cobranças
✓ Consultar cobranças
✓ Consultar status de pagamentos
✓ Criar cobranças PIX
✓ Criar cobranças por boleto
✓ Criar cobranças por cartão
✓ Criar e gerenciar assinaturas

A aplicação poderá realizar somente as ações autorizadas.

Botões:

[ Cancelar ]

[ Autorizar aplicação ]

5. Authorization Code

Após a autorização, o Asaas redirecionaria o usuário de volta para a aplicação:

https://api.aplicacao.com/integracoes/asaas/callback?code=XXXX&state=YYYY

Esse code deveria:

possuir validade curta;
ser de utilização única;
não representar diretamente o token de acesso.

6. Troca segura do code

O backend da aplicação faria a troca do authorization code por um token através de comunicação server-to-server.

Conceitualmente:

POST /oauth/token

Utilizando:

client_id
client_secret, quando aplicável
code
redirect_uri
code_verifier, caso PKCE seja utilizado

O Asaas retornaria algo semelhante a:

{
"access_token": "...",
"refresh_token": "...",
"token_type": "Bearer",
"expires_in": 3600,
"scope": "customer.read customer.write payment.read payment.write"
}
Permissões granulares

Um dos pontos mais importantes seria permitir que a aplicação solicite somente as permissões necessárias.

Exemplos de scopes:

account.read

customer.read

customer.write

payment.read

payment.write

subscription.read

subscription.write

pix.read

pix.write

webhook.read

webhook.write

Assim, um software que precise apenas criar cobranças não precisaria receber acesso a configurações administrativas ou recursos não relacionados.

Exemplo prático

Somos uma plataforma SaaS de gestão para estabelecimentos.

Um de nossos clientes possui sua própria conta Asaas.

Queremos permitir que ele simplesmente clique:

[ Conectar minha conta Asaas ]

O cliente seria direcionado ao Asaas, faria login e autorizaria:

Permitir que esta aplicação crie e consulte cobranças na minha conta.

Depois disso, nossa aplicação poderia criar uma cobrança usando a conta daquele estabelecimento.

Por exemplo:

Cliente paga R$ 89,90

↓

Nossa aplicação solicita a criação da cobrança

↓

A cobrança é criada diretamente na conta Asaas do estabelecimento

↓

O dinheiro continua pertencendo e sendo recebido diretamente pelo estabelecimento.

Nossa aplicação apenas possuiria a autorização necessária para operar os recursos previamente aprovados.

Gerenciamento das aplicações conectadas

Também seria muito interessante disponibilizar dentro do próprio painel Asaas uma página:

Minha Conta → Segurança → Aplicações conectadas

Exemplo:

Aplicações conectadas

Navo

Conectado em: 13/09/2026

Permissões:

Criar cobranças
Consultar cobranças
Criar clientes
Consultar clientes
Gerenciar assinaturas

Último acesso:

13/09/2026 às 21:42

[ Revogar acesso ]

Ao clicar em "Revogar acesso", os tokens associados àquela aplicação seriam imediatamente invalidados sem necessidade de alterar a API Key principal da conta.

Segurança

Para tornar o recurso seguro, sugerimos a utilização de mecanismos como:

OAuth 2.0 Authorization Code Flow;
PKCE;
parâmetro state contra ataques CSRF;
Authorization Code de uso único;
Authorization Code com duração curta;
Access Tokens com expiração;
Refresh Tokens;
rotação de Refresh Tokens;
permissões através de scopes;
revogação individual por aplicação;
Redirect URIs previamente cadastradas;
possibilidade de revisão da aplicação pelo Asaas;
identificação clara da aplicação durante a autorização;
registro de data, IP e aplicação que realizou operações;
webhook para informar revogação de autorização;
opção para o usuário visualizar aplicações conectadas.

Também seria interessante permitir ao proprietário da conta visualizar um histórico como:

Aplicação "Navo" criou cobrança pay_xxxxx no valor de R$ 89,90.

Isso aumentaria ainda mais a transparência.

Portal para desenvolvedores

O Asaas poderia disponibilizar uma área onde empresas integradoras cadastrariam suas aplicações.

Exemplo:

Desenvolvedores → Minhas aplicações

Informações:

Nome da aplicação
Logo
Empresa responsável
URL
Política de privacidade
Termos de uso
Redirect URIs permitidas
Webhook
Ambiente Sandbox
Ambiente Produção

Após o cadastro seria fornecido:

client_id
client_secret, quando necessário

Também poderia existir um processo de homologação para aplicações que solicitassem permissões financeiras consideradas mais sensíveis.

Sandbox

Seria muito importante disponibilizar o mesmo fluxo no Sandbox.

Dessa maneira poderíamos testar todo o processo:

Conectar conta →

Autorizar →

Receber Authorization Code →

Obter Access Token →

Criar cliente →

Criar cobrança →

Receber webhook →

Revogar autorização.

Sem envolver uma conta real durante o desenvolvimento.

Benefícios para o Asaas

A funcionalidade facilitaria significativamente a adoção do Asaas por:

ERPs;
CRMs;
sistemas para barbearias;
sistemas para salões;
sistemas jurídicos;
plataformas SaaS;
marketplaces;
plataformas de assinatura;
sistemas financeiros;
sistemas de gestão;
plataformas white-label.

Em vez de cada software ensinar:

"Entre no Asaas → vá em configurações → integração → gere uma API Key → copie → volte ao nosso sistema → cole aqui."

o fluxo seria simplesmente:

[ Conectar com Asaas ]

Login →

Autorizar →

Conectado.

Impacto esperado

Acreditamos que essa funcionalidade poderia trazer benefícios relevantes para todo o ecossistema Asaas.

Para o usuário
integração muito mais simples;
nenhum compartilhamento manual de API Key;
maior segurança;
clareza sobre o que cada aplicação pode acessar;
possibilidade de revogar individualmente uma integração.
Para desenvolvedores
onboarding muito mais simples;
menor necessidade de suporte;
integração padronizada;
maior segurança no armazenamento de credenciais;
possibilidade de criar experiências de integração realmente "1 clique".
Para o Asaas
aumento do número de integrações;
maior utilização das APIs;
maior adoção por plataformas SaaS;
criação de um ecossistema mais forte de aplicações;
maior segurança do que distribuir API Keys entre sistemas terceiros;
maior competitividade frente a outros meios de pagamento que já oferecem experiências semelhantes de conexão/autorização.
Resumo da proposta

A sugestão é permitir que uma aplicação terceira possa solicitar:

"Autorize esta aplicação a criar e consultar cobranças na sua conta Asaas."

O cliente entra diretamente no Asaas, visualiza exatamente quais permissões serão concedidas e autoriza.

A aplicação recebe um token restrito às permissões concedidas, sem precisar conhecer a senha ou receber manualmente a API Key principal do cliente.

Em outras palavras:

um "Login com Asaas", porém voltado para autorização de operações financeiras e integração de sistemas.

Acreditamos que essa funcionalidade reduziria bastante a barreira de integração do Asaas com plataformas SaaS e permitiria uma experiência muito mais segura, moderna e simples para clientes e desenvolvedores.