Para configurar novos métodos de autenticação para conectores de dados, vá para Configurações > Integrações > Autenticação e clique em Adicionar token.

Você tem duas abordagens principais para configurar um token: conectar um provedor pré-configurado ou criar um token personalizado:

Oferecemos fluxos OAuth pré-configurados de 3 etapas para provedores suportados (como Salesforce, HubSpot e Attio) para tornar a autenticação rápida e fácil.

Para conectar um desses provedores:

Quando o fluxo OAuth for concluído, seu novo token de acesso aparecerá automaticamente na sua lista de tokens.

Clicar no token recém-criado exibirá sua configuração. Como esta é uma integração pré-configurada, apenas os campos Nome e Descrição são editáveis. Você também verá:

Se um token for desativado ou quebrado no lado do provedor, não é necessário excluí-lo e começar de novo. Basta abrir os detalhes do token e clicar no botão Reautenticar no canto superior direito. Isso o levará novamente pelo fluxo OAuth e atualizará automaticamente seu token existente, garantindo que seus conectores de dados conectados continuem funcionando sem atualizações manuais.

Se você precisar se conectar a um serviço que não está incluído na lista pré-configurada:

Tokens de texto são tokens estáticos. Você pode definir o nome do token, descrição, valor, prefixo do token e a chave para o cabeçalho da requisição que contém o token, que será inserido na requisição do conector de dados.

Tokens de requisição HTTP são dinâmicos. Você configura uma requisição HTTP para seu Endpoint de Autenticação que atualizará o token quando necessário. Esses tokens devem ser testados na interface de token de autenticação antes de serem salvos. Você pode definir o nome do token, descrição e os campos que afetam a requisição em si. Estes são o método da requisição HTTP, URL, cabeçalhos HTTP e quaisquer pares chave-valor.

Você deve testar o token clicando em Testar requisição e então especificar a localização do token na resposta, o prefixo do token e a chave para o cabeçalho da requisição.

Se um token de requisição HTTP for atribuído a um conector de dados, o conector usará o token mais recentemente obtido para suas requisições. Se uma requisição retornar uma resposta 400, 401 ou 403, o token será atualizado enviando uma requisição HTTP para a URL do Endpoint de Autenticação especificada. A requisição original do conector de dados será então tentada novamente usando o token recém-obtido.

Tokens de requisição HTTP são atualizados automaticamente pelo Intercom para manter os conectores de dados funcionando. Essas atualizações acontecem em segundo plano sem qualquer ação humana e podem aparecer como atualizadas por “System” ou “Fin” para indicar uma atualização automatizada.

Se houver um problema ao atualizar um token, o problema será registrado na aba "Logs" do conector de dados.

Requisições OAuth permitem solicitar e atualizar tokens fazendo uma requisição POST com o formato OAuth client credentials grant.

Por favor, forneça o url, client_id, client_secret e o campo opcional scope. Selecione o formato da requisição JSON ou Form Encoded com base na configuração do seu servidor de token.

Uma prévia do cabeçalho e corpo da requisição será exibida.

Clique em Testar requisição depois de preencher todos os campos obrigatórios.

O Intercom procurará o token na resposta no caminho access_token.

Salve o token assim que o teste for aprovado.

Semelhante ao token de requisição HTTP, o sistema realizará uma atualização do token se uma requisição do conector de dados receber uma resposta 400, 401 ou 403.

Tokens de requisição OAuth são atualizados automaticamente pelo sistema quando necessário. Essas atualizações não são acionadas por um administrador humano e podem aparecer como atualizadas por “System” ou “Fin” para indicar uma atualização automatizada.

Tokens de usuário permitem autenticar conectores de dados usando um token definido pelo usuário. Esses tokens são criados e atualizados por sistemas de terceiros. Um dos exemplos mais populares desse token é JSON Web Tokens (JWT).

JWT é uma forma segura de verificar a identidade do usuário. Agora você pode usar esse novo tipo de token de autenticação para proteger seus conectores de dados. Isso permite uma comunicação mais flexível e segura entre seus sistemas e o Intercom.

Uma vez que seu tipo de token esteja criado:

Toda a gestão de tokens de usuário é feita por sistemas de terceiros.

Esses sistemas de terceiros também são responsáveis por atualizar o token de segurança e atualizá-lo periodicamente.

Você pode anexar múltiplos tokens a um único conector de dados. Cada token anexado deve ser configurado com uma chave de cabeçalho única (ex.: Authorization, X-API-Key). Todos os tokens anexados serão enviados com a requisição.

Essa configuração permite que você acione conectores de dados usando esse token - seja através de Workflows ou Fin. O conector de dados continuará funcionando mesmo se o valor do token for atualizado, pois ele será atualizado em tempo real para garantir autenticação ininterrupta.

Para usar um JWT por usuário com um conector de dados, crie um token de autenticação ‘User’ e forneça seu valor atual via auth_tokens (ex.: Intercom('setAuthTokens')), em vez de depender do Messenger intercom_user_jwt.

Verificação de e-mail para conectores de dados com OTP oferece uma etapa adicional de verificação antes que um conector de dados seja usado, exigindo que os clientes verifiquem sua identidade por meio de um código único e sensível ao tempo enviado por e-mail.

Esse método adiciona uma camada extra de segurança além dos tokens de autenticação de usuário (ex.: JWTs). Quando ativado, os clientes devem completar o processo de verificação por e-mail antes que um conector de dados possa prosseguir. Isso ajuda a garantir que apenas usuários autorizados possam realizar operações sensíveis e previne o uso indevido de workflows automatizados.

A autenticação de clientes permite verificar a identidade de um cliente antes que um conector de dados seja executado. Diferente da autenticação por token API (que protege a comunicação servidor a servidor), a autenticação de clientes confirma a identidade do usuário final — garantindo que apenas clientes autorizados possam acionar conectores sensíveis.

As regras de autenticação são configuradas em Configurações > Workspace > Segurança > Autenticação de clientes e se aplicam a todos os conectores de dados que tenham autenticação ativada. As regras podem ser definidas por canal e por público.

Uma regra de fallback cobre todos os canais e públicos não especificados, garantindo que todo conector autenticado esteja sempre protegido.

Quando um novo workspace é criado, a regra de autenticação de fallback é automaticamente definida para Email OTP. Isso cobre todos os canais e públicos não especificados por uma regra mais específica.

Quando você cria uma nova regra de canal ou público, um método de autenticação padrão é aplicado com base no tipo de canal:

Dois métodos de verificação estão disponíveis:

A autenticação deve ser ativada individualmente para cada conector de dados onde você deseja que ela seja aplicada:

Uma vez ativado, o conector aplica as regras de autenticação do workspace que se aplicam ao canal e público da conversa recebida.

A página de Credenciais (Configurações > Integrações > Credenciais) oferece uma visão centralizada de todas as credenciais de autenticação usadas em seus conectores de dados. A tabela mostra nome, tipo, quem criou e quem atualizou por último — facilitando a auditoria de acesso a sistemas externos.

Tokens baseados em texto são simples — o conector de dados usa o valor do token atribuído sempre que testa ou envia uma requisição ao vivo do conector de dados.

Tokens de requisição HTTP seguem um fluxo mais complexo. Para testes e conectores de dados ao vivo, o conector de dados usará primeiro o token mais recentemente obtido. Se a requisição falhar, ele enviará uma requisição de atualização e então tentará novamente o conector de dados usando o novo token. Essa tentativa ocorre apenas uma vez para evitar um loop infinito.

Se o conector de dados continuar falhando devido a falhas nas requisições de atualização, ele acionará o disjuntor, assim como qualquer conector de dados que encontre falhas repetidas.