Visão geral

A API de documentos para serviços eSign da Document Cloud foi projetada para ser perfeitamente integrada ao seu aplicativo existente, sem a necessidade da realização de um processo de registro eSign gerenciado por serviços. Consequentemente, o aplicativo anexado é responsável por assegurar que o remetente é um usuário de serviços eSign. Ele registra os usuários de forma programática usando a API se eles ainda não estiverem registrados. Os destinatários não são obrigados a se registrar. Os serviços eSign sempre controlam quais interações são necessárias por parte do destinatário.

Especifique o remetente do documento

Existem diversas maneiras de especificar um remetente ao iniciar uma nova transação com o método sendDocument. O comportamento depende de quais valores são transmitidos usando o parâmetro opcional SenderInfo.

  • Null SenderInfo: nesse caso, o remetente do documento é o usuário exclusivo específico associado à chave de API que está sendo usada. Este método é adequado para testes e algumas implantações de escopo limitado, mas, geralmente, não é útil para integrações em grande escala com conjuntos de usuários existentes.
  • SenderInfo com email e senha: nesse caso, o remetente do documento é o usuário especificado pelo parâmetro de email. A senha fornecida deve ser igual à senha EchoSign do usuário. Para integrações, o email e senha podem ser solicitados ao usuário, dentro do contexto do aplicativo em anexo quando o documento estiver prestes a ser enviado. Como alternativa, o aplicativo anexado pode lembrar o email e a senha porque o aplicativo criou o usuário ou porque o usuário forneceu esta informação anteriormente e ela foi armazenada em cache.
  • SenderInfo com email e sem senha: nesse caso, o remetente do documento é o usuário especificado pelo parâmetro de email. O valor da senha deve ser nulo. O EchoSign verifica se quem solicitou a API e o remetente pretendido pertencem à mesma conta, mas não exige ou verifica a senha. Esse método pode ser adequado para integrações de API dentro de uma organização específica, mas há uma diminuição na segurança individual. Este modelo de autenticação deve ser solicitado explicitamente pelo proprietário master da conta para que seja disponibilizado para uso com a API do EchoSign.

Gerenciamento da conta dos serviços eSign

Conforme descrito acima, na maioria dos casos, você deseja fornecer o email e a senha do usuário em nome do qual está enviando o documento. A seção a seguir resume as diferentes formas de obter informações.

Solicitar ao usuário

Solicite ao usuário seu email e senha dos serviços eSign como parte do processo de envio. Você pode usar o método verifyUser para verificar se o usuário está inscrito nos serviços eSign e que senha é válida. Se o usuário não estiver registrado, você pode pedir que ele crie sua própria conta dos serviços eSign ou pode criar uma para ele (veja abaixo).

Criar a conta

Se uma chamada para o verifyUser mostra que não existe nenhum usuário com este endereço de email, você pode criar, de maneira programada, um usuário de serviços eSign realizando uma chamada createUser. Considerando que a criação do usuário foi bem-sucedida, o email e a senha fornecidos agora podem ser usados como o SenderInfo para seu documento.

Lembrar a conta

Após passar por um dos cenários acima, você pode optar por lembrar o email e a senha do usuário e usá-los como o SenderInfo para enviar documentos subsequentes em nome do usuário. O usuário pode fazer o logon em sua conta dos serviços eSign e alterar a senha a qualquer momento, por isso, seu aplicativo deve estar preparado para o caso de uma senha salva anteriormente se tornar inválida.

Conclusão

Existem várias maneiras diferentes de determinar a identidade do remetente ao usar a API de documentos dos serviços eSign. Leia as informações acima cuidadosamente para decidir qual método é apropriado para o seu aplicativo. Caso tenha dúvidas, entre em contato conosco.

Esta obra está licenciada sob uma licença não adaptada da Creative Commons Attribution-Noncommercial-Share Alike 3.0  As publicações do Twitter™ e do Facebook não são cobertas pelos termos do Creative Commons.

Avisos legais   |   Política de privacidade online