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 seu workspace Fin.

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

Dito isso, o guia abaixo ainda contém instruções úteis, 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 seu workspace Fin.

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 na 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 pelo Messenger em vez de 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 requisição para API usando “GET /accounts/<account_id>/invoices”, você quer ter certeza que account_id está protegido para que o user não possa simplesmente enumerar account_ids coletando dados. Porém, se seu Data Connector é "GET /pizza-order-status/<order_id>" então talvez você não se importe com a confiabilidade de "order_id" e não se importe 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 é a assinatura do 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 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.

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 devem realizar uma avaliação de risco e criar métodos apropriados para lidar com autenticação e autorização.

Atualmente, suportamos tokens estáticos, tokens HTTP e OAuth. Qualquer token que você use, é sua responsabilidade garantir que ele seja mantido em segredo e atualizado rapidamente se for 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 sua Task/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 Connectors é 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 retorna 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 para o user digitar seu ID de conta, mas apresentar a ele seus IDs de conta (baseado em um identificador conhecido e seguro) e deixá-lo escolher em uma lista suspensa.