Data connectors usam APIs para conectar a sistemas externos para buscar e/ou atualizar dados existentes. Por isso, é importante ter algumas coisas em mente ao configurar Data connectors no Intercom.

Se você está utilizando APIs de terceiros (não construídas internamente) com Data connectors no Intercom, provavelmente tem pouco ou nenhum controle sobre como elas funcionam ou a resposta que recebe de uma solicitação.

Dito isso, o guia abaixo ainda é uma orientação útil, mas algumas seções podem não ser totalmente aplicáveis ao seu caso de uso.

Nossos engenheiros compilaram uma lista de pontos a observar ao projetar ou modificar suas APIs existentes para funcionar com Fin e Data connectors no Intercom.

Primeiro, recomendamos fortemente que você ative a Segurança do Messenger com JWTs. Proteger seu Messenger é o controle de segurança mais importante para configurar em sua integração.

Isso também permite que você assine múltiplos atributos via nossa API JavaScript, para que possa enviar dados sobre seus users com segurança através do Messenger, em vez de precisar usar outra integração, por exemplo: REST API.

Para aproveitar os benefícios de enviar dados com segurança, você pode proteger seus atributos contra atualizações inseguras do Messenger e então qualquer JWT enviado, que consideramos uma fonte segura, ainda atualizará esse campo no user. Isso é crucial para Data connectors, quando o Data connector exibe dados sensíveis ou manipula dados.

Por exemplo, se seu Data connector está fazendo uma solicitação para API usando “GET /accounts/<account_id>/invoices”, então você quer ter certeza de que account_id está protegido para que o user não possa simplesmente enumerar account_ids coletando dados. No entanto, se seu Data connector é "GET /pizza-order-status/<order_id>" então você pode não se importar com a confiabilidade de "order_id" e não se importa se essa informação foi exibida para a pessoa certa.

Além disso, você deve garantir que o atributo que seu Data connector usa para identificar unicamente seus users (email, por exemplo) seja confiável. Isso significa que você precisa saber que confia na fonte dos atributos identificadores do seu Data connector. Por exemplo, se seu Data connector identifica o user por user_id, a verificação de identidade é assinar o atributo user_id ou se seu Data connector identifica o user por email ou qualquer outro atributo, então esse atributo está protegido e não é coletado do End User sem alguma verificação.

Isso impede que agentes maliciosos possam, por exemplo, fornecer o endereço de email de outra pessoa e acessar um Data connector como “Get bank statements by email”, o que exporia dados financeiros sensíveis.

Sempre que possível, sugerimos que você não use email como identificador principal para buscar dados dos seus users, mas algo mais aleatório, como um ID de user único e não previsível.

Para realizar a verificação de identidade em leads, nossa equipe está atualmente trabalhando em um recurso de One Time Password (OTP) que ajudará você a verificar a identidade de alguém se essa pessoa estiver entrando em contato com seu suporte como lead. Se estiver interessado nesse recurso, sinta-se à vontade para contatar nossa equipe de Suporte via Messenger e eles ficarão felizes em ajudar a ativá-lo.

Você também deve garantir que o user não possa executar Data connectors que não está autorizado a fazer, por exemplo, cancelar o pedido de outra pessoa sabendo o ID do pedido. Essa lógica não é tratada dentro do Intercom e você/sua equipe de segurança deve realizar uma avaliação de risco e criar métodos apropriados para lidar com autenticação e autorização.

O Intercom atualmente suporta tokens estáticos, tokens HTTP e OAuth (beta fechado, entre em contato conosco via Messenger para mais informações). Qualquer token que você use, é sua responsabilidade garantir que ele seja mantido em segredo e atualizado rapidamente caso seja vazado em algum lugar. Como boa prática, recomendamos o uso de tokens OAuth sempre que possível.

Idealmente, a API deve retornar apenas os dados necessários para seu Workflow. No entanto, isso pode ser irrealista e a API pode retornar uma boa quantidade de dados que na verdade não são necessários para executar o Workflow onde o Data connector é usado.

Se você está construindo APIs do zero para serem usadas exclusivamente com Data connectors e Fin Workflows, você pode:

Algumas considerações que devem ser incluídas ao decidir quais e quanto dados sua API deve retornar incluem:

Além disso, você deve sempre remover a possibilidade de users fornecerem dados malformados ou simplesmente digitarem qualquer coisa.

Por exemplo, você não deve pedir ao user para digitar seu ID de conta, mas apresentar a ele seus IDs de conta (baseados em um identificador conhecido e seguro) e deixá-lo escolher em uma lista suspensa. Mais sobre como coletar dados dos users pode ser encontrado aqui.