Segurança

Isolamento por empresa

Toda leitura é filtrada pela empresa que está no token de acesso. A empresa vem da claim do token, nunca de um parâmetro da requisição, então não existe entrada capaz de ampliar o escopo de uma credencial.

Para parceiros, a empresa gravada na sessão do WhatsApp também deve corresponder à empresa da credencial. Um vendedor compartilhado ou uma sessão sem empresa não permite cruzar esse limite. Empresas legadas confirmadas mantêm a seleção de vendedores existente.

Os recursos são endereçados por identificadores opacos com prefixo (mtg_, call_, usr_, tpl_, acc_, team_, tag_), alocados por empresa. Ids internos sequenciais nunca são expostos, então não dá para inferir volume nem enumerar ids. A única forma de enumerá-los é pelos catálogos (/v1/accounts, /v1/teams, /v1/tags), que devolvem as contas, times e tags da própria empresa e nada mais. Um id de outra empresa usado como filtro produz página vazia, nunca um erro que confirmaria sua existência.

Um identificador que não é da sua empresa devolve 404, nunca 403 — a API não confirma que o recurso existe em outro lugar.

A credencial de usuário vê o que o dono vê

A credencial de usuário estreita o isolamento por empresa; nunca o amplia. A cada requisição a API calcula, a partir do estado atual no Salesbud, o que o dono enxerga, e serve só isso.

Recurso	Credencial de empresa	Credencial de usuário
Reuniões e ligações, com transcrições, respostas e avaliações	Todos os registros da empresa	Registros dos donos que a pessoa vê pelos times dela, mais os compartilhados com ela
Conversas de e-mail	Todas as conversas da empresa	Só com acesso a e-mail no Salesbud; conversas das caixas que a pessoa vê, ou todas para administrador da plataforma
Conversas de WhatsApp	Todas, das duas fontes	Só as fontes que a pessoa pode usar; conversas dos vendedores que ela vê
/v1/teams	Todos os times	Os times de que a pessoa é membro
/v1/tags	Todas as tags	Todas para administrador da plataforma; senão, tags sem time e sem grupo, as dos times da pessoa e as dos grupos que ela alcança
/v1/accounts	Todas as contas	Todas as contas, como no Salesbud; com a funcionalidade ACCOUNTS desligada na empresa, /v1/accounts vem vazio, accounts volta como [] em reuniões, ligações e conversas de e-mail e WhatsApp, e filtrar por account_id devolve página vazia
Filtro team_id	Qualquer time da empresa	Time de que a pessoa não é membro vale como desconhecido: página vazia

Um registro fora dessa visão devolve 404, igual a registro de outra empresa, então a credencial de usuário não confirma que algo existe. Perder o acesso a e-mail ou WhatsApp no Salesbud durante a vida do token devolve 403 INSUFFICIENT_SCOPE nessas rotas; um registro que sai da visão do dono deixa de aparecer e devolve 404.

As regras espelham o produto, divergências incluídas

“O que uma pessoa vê” não é uma regra só no Salesbud, e a API copia cada regra como está, em vez de unificá-las:

	Reuniões, ligações, transcrições	E-mail e WhatsApp	Tags
Papel do dono	Efetivo: master no time padrão conta como member	O atribuído	Não se aplica: só pertencer ao time ou grupo
Administrador da plataforma	Sem atalho	Vê tudo	Vê tudo

A consequência visível: um master no time padrão aparece para os admins do time em reuniões, mas não em e-mail e WhatsApp, onde nenhum membro de time o vê, só o admin de plataforma.

Administradores não solicitam credencial de usuário, então as linhas de administrador só valem quando o dono vira administrador depois da aprovação.

O que a credencial de usuário não faz

• Não atravessa empresas. Quem alcança várias empresas no Salesbud precisa de uma credencial por empresa, cada uma aprovada pelos administradores daquela empresa.
• Mudanças levam até 60 segundos. A visão fica em cache por no máximo 60 segundos, então uma troca de time, um compartilhamento novo ou uma permissão retirada chega à API dentro dessa janela. Revogar ou desativar a credencial vale na hora.

Empresa proprietária da reunião

Reuniões e ligações seguem a empresa padrão do dono no momento da leitura, tanto em empresas diretas quanto em contas nativas de parceiros ou convertidas. Metadados históricos do evento não alteram essa atribuição. Ao mudar a empresa padrão, o histórico do dono acompanha essa empresa. Cada leitura continua exigindo uma credencial da empresa e as permissões de visibilidade existentes.

A reunião mantém a referência do template e as respostas históricas quando a empresa padrão do dono muda. O nome passa a ser Template quando o nome atual daquele template está fora do escopo da empresa da credencial. O nome real continua disponível para templates do próprio dono da reunião, templates cujo autor tem essa empresa como padrão e templates compartilhados explicitamente com uma equipe dessa empresa. Um vínculo secundário com a empresa, sozinho, não expõe os nomes dos templates do autor.

O acesso ao produto usa as features persistidas da empresa e as permissões do dono em todas as contas. A oferta comercial do parceiro não revoga uma feature já concedida à empresa. Novos tokens exigem a feature do aplicativo solicitante; tokens emitidos mantêm sua duração normal, e revogar a credencial continua valendo na hora. Mudanças de visibilidade e permissão do dono seguem o cache existente, de até 60 segundos.

Sessões do WhatsApp com empresa salva devem corresponder à empresa da credencial em todas as contas. Sessões Baileys sem empresa usam a resolução legada de empresa habilitada do dono, restrita aos vendedores autorizados; sessões antigas do RD Conversas e Umbler usam o prefixo da empresa. Um vendedor compartilhado não libera a sessão explícita de outra empresa.

Transcrições têm portão próprio

transcriptions.read é um escopo distinto de meetings.read e calls.read, e uma credencial pode ter os escopos de coleção sem ele. A transcrição é o dado mais sensível que a API serve — a fala literal do cliente — então acessar o metadado de uma reunião não implica acessar o que foi dito nela.

O portão soma em vez de substituir o escopo da coleção: a requisição de transcrição é checada contra os dois, então uma credencial restrita a ligações não alcança transcrição de reunião por ter transcriptions.read.

O texto da transcrição é sanitizado antes de sair do serviço.

Tudo é auditado

Toda leitura de negócio é registrada: qual credencial, qual empresa, qual rota, quais ids de recurso e qual identidade chamou.

A gravação da auditoria é fail closed. Se a trilha não puder ser escrita, a leitura não é devolvida — você recebe 503 AUDIT_UNAVAILABLE. Uma resposta bem-sucedida, portanto, significa que o acesso ficou registrado.

Higiene de credencial

• Os secrets são guardados apenas como hash HMAC-SHA256 com pepper do serviço. Não podem ser lidos de volta, só rotacionados.
• A rotação de uma credencial de empresa mantém o secret anterior válido por sete dias para você fazer deploy sem downtime; revogue assim que o novo estiver no ar. Rotacionar uma credencial de usuário para o secret anterior na hora.
• Em suspeita de vazamento, revogue o client — isso invalida os tokens emitidos na hora. A rotação não invalida os tokens já emitidos, e na credencial de empresa o secret antigo também continua valendo.
• Configure allowlist de IP quando a integração roda de endereços fixos. Ela vale na emissão e em toda requisição, então um token vazado não serve de fora.
• Prefira credencial de usuário para uso pessoal, como um script no seu notebook: ela lê só o que você vê e morre com o seu vínculo. Deixe as credenciais de empresa para integrações que precisam ler a empresa inteira.

O que nunca sai do serviço

Stack trace, caminho de arquivo, id interno, token, secret e corpo de requisição nunca são devolvidos numa resposta, nem escritos em log.