Chaves API e aplicações ligadas

O Styrar oferece dois estilos comuns de integração: chaves API para os seus próprios scripts e servidores, e aplicações ligadas para produtos de terceiros que os utilizadores autorizam através de OAuth. Ambos podem acessar dados do espaço de trabalho de acordo com as capacidades concedidas, mas destinam-se a situações diferentes.

Use chaves API quando controla o código que vai chamar o Styrar, como um script interno, uma tarefa de servidor, um executor de fluxos de trabalho, ou um cliente MCP que usa um token de portador. Use aplicações ligadas quando um produto externo pede a um utilizador para aprovar acesso através de um ecrã de consentimento.

Chaves API

Em Definições → Chaves API, crie chaves para automação e tarefas de back-end. Trate as chaves como palavras-passe: guarde-as com segurança, rode-as se forem expostas, e revogue as que já não usa. Não cole chaves em produção em código público, capturas de ecrã, tickets, ou código de navegador do lado do cliente.

Boas práticas para chaves API:

• Crie chaves separadas para sistemas separados.
• Dê a cada chave um nome reconhecível.
• Conceda apenas as capacidades de que a integração precisa.
• Guarde as chaves num gestor de segredos ou variável de ambiente do servidor.
• Rode as chaves quando membros da equipa mudarem ou os registos possam ter sido expostos.
• Revogue chaves de teste antigas depois de a configuração estar concluída.

Se um script falhar com um erro de autorização, verifique se a chave tem a capacidade necessária e pertence ao espaço de trabalho pessoal ou de empresa esperado. Uma chave criada num âmbito pode não ter acesso a recursos noutro.

Para clientes MCP, use a chave API do Styrar como token de portador quando o cliente pedir um token MCP remoto por HTTP ou ao configurar o modo stdio com uma variável de ambiente. Os campos de ID de cliente e segredo de cliente OAuth em algumas ferramentas não são o mesmo que uma chave API do painel.

Aplicações ligadas

Em Definições → Aplicações ligadas, reveja as aplicações OAuth que os utilizadores aprovaram. Cada entrada mostra o que foi concedido. Desligue tudo o que já não deva acessar o espaço de trabalho. As aplicações ligadas estão associadas a um consentimento real do utilizador, por isso cada utilizador deve rever periodicamente que produtos autorizou.

Uma aplicação pode pedir acesso de leitura, acesso de escrita, ou uma combinação de capacidades. O acesso final concedido pode ser limitado pela própria lista de permissões da aplicação, pelo consentimento do utilizador, e pelas permissões do utilizador no espaço de trabalho. Se uma aplicação não conseguir realizar uma ação, pode precisar de reautorização depois de os âmbitos ou capacidades do produto mudarem.

Desligar uma aplicação interrompe o acesso futuro através dessa concessão OAuth. Se o produto de terceiros também guardar dados do seu lado, verifique as definições desse produto se quiser remover a sua cópia local ou estado de integração.

Consentimento OAuth

As aplicações de terceiros encaminham as pessoas através de um ecrã de consentimento. Os utilizadores só devem aprovar aplicações em que confiam e que correspondem à ferramenta que pretendiam ligar. Leia o acesso solicitado antes de aprovar. Se a aplicação pedir mais acesso do que esperado, cancele e verifique a documentação da integração.

Para equipas, decida quem tem permissão para ligar aplicações de terceiros. Alguns espaços de trabalho mantêm a aprovação OAuth limitada a proprietários ou administradores. Outros permitem que os membros liguem ferramentas de produtividade mas restringem os âmbitos de faturação, definições da empresa ou publicação.

Escolher a integração certa

Escolha uma chave API quando:

• A integração corre no seu servidor.
• Não há um fluxo de aprovação individual do utilizador.
• Precisa de uma credencial estável para automação.
• Pode guardar segredos com segurança fora do navegador.

Escolha OAuth quando:

• Um produto de terceiros está a ligar-se em nome de um utilizador.
• O utilizador deve rever um ecrã de consentimento.
• O acesso deve ser revogável por aplicação.
• A integração precisa de respeitar as permissões do espaço de trabalho de cada utilizador.

Se uma chave ou aplicação for exposta

Revogue-a imediatamente nas definições. Crie uma substituição só depois de compreender onde a credencial antiga estava guardada. Se a credencial exposta tinha acesso de escrita, reveja a atividade recente e os registos de auditoria onde disponível.

Precisa de mais ajuda?

Abra um ticket em Ajuda → Tickets (sessão iniciada obrigatória).