Requisição HTTP

Já vimos sobre as integrações nativas e como elas ajudam a integrar a Suri aos CRMs mais utilizados no mercado. Mas e se minha integração ainda não estiver na lista das suportadas pela Suri? Sinta-se à vontade para utilizar um nos nossos recursos mais poderosos: a integração de requisição HTTP.

Com a ação de Requisição HTTP, você pode definir tudo o que uma chamada HTTP faz mas sem tocar em nenhuma linha de código

Já deu para perceber que o conceito de ação de Requisição HTTP é basicamente uma chamada HTTP que já conhecemos, onde podemos definir:

• o método (GET, POST, etc.);

• parâmetros da url (o famoso ?param1=value1&param2=value2);

• cabeçalhos (Headers) com dados importante como autenticação;

• o tipo de conteúdo (Content-Type) que estamos enviando no corpo da requisição

• o corpo (Body) da requisição em si, onde devemos montar o objeto de acordo com o Content-Type

O dado enviado no Body deve ser estruturado de acordo com o Content-Type escolhido. Por exemplo, para Content-Type = json, devemos seguir um formato JSON:

{
    "id": "123456",
    "name": "João Silva",
    "foo": "bar"
}

Para Content-Type = xml, devemos enviar um XML válido:

<User>
    <Id>123456</Id>
    <Name>João Silva</Name>
    <Foo>bar</Foo>
</User>

Já para Content-Type = form-urlencoded ou formdatadevemos mandar como objeto chave:valor separados por quebra de linha:

id:123456
name:João Silva
foo:bar

Isso já é o bastante para efetuar a requisição seguindo os parâmetros estabelecidos. Vamos simular uma situação bem rotineira: geração de boleto.

• O contato fala com sua empresa solicitando a segunda-via de seu boleto

• A Suri, por meio do flow apropriado, captura os dados que precisa para atender esta solicitação (apenas o CPF, vamos supor)

• Por fim, utilizando a ação de requisição HTTP, chamamos sua API com o CPF do contato (utilizando @User.IdentificationDocument, para mais detalhes rever a página Utilizando dados do contato) no Body da requisição.

Caso sua API apresente falha, não se preocupe: isso não irá quebrar o fluxo da Suri. O flow irá continuar normalmente, enviando as demais ações, caso existam, e registrando o erro em nossos logs para fins de consulta.

Agora vem um ponto extremamante importante: o que fazemos com a resposta de tal chamada HTTP?

Retorno da API

Atualmente contamos com três formas de tratar o retorno de sua API:

• Nenhum tratamento: é o comportamento padrão. Ideal para casos onde não necessitamos de um tratamento para o retorno, como por exemplo, registrar um novo lead em um CRM. A Suri apenas executa a chamada HTTP e continua a execução do fluxo.

• Retorno vinculado à Suri: apropriado para casos onde você desenvolveu sua API unicamente para integração com a Suri. Esta API deve retornar um objeto específico que representa uma mensagem a ser retornada ao contato final.

• Retorno livre: perfeito para quando você já possui uma API e deseja que a Suri se adapte ao retorno da mesma. Dessa forma, independente do tipo de retorno da API, a Suri consegue capturar informações e utilizá-las ao longo do fluxo.

Te convidamos para entender melhor sobre as duas últimas formas de retorno nas páginas a seguir:

Retorno vinculado à Suri

Retorno livre