O que vai construir
Uma automação com quatro partes:- Um trigger para o momento que vale a pena reportar
- Uma tarefa HTTP Request que faz POST de JSON para o seu endpoint, autenticada com um bearer token
- Uma resposta descrita, para que o que o endpoint devolve se torne campos
- Uma tarefa posterior que utiliza um desses campos
Esta receita envia dados para fora da HireData. Se precisa da direção oposta, em que outra ferramenta envia dados para dentro para iniciar uma automação, use antes um trigger de app personalizada. Veja Apps personalizadas e Configurar um trigger.
O que pedir antes de começar
Quem é dono do endpoint tem tudo isto. Obtê-lo à partida poupa uma ronda de adivinhação:- O URL a chamar, e o método que espera
- O corpo que espera, idealmente como um payload JSON de exemplo em vez de uma descrição
- Como autentica. Esta receita usa um bearer token emitido para esta integração, não o token pessoal de alguém
- O que devolve, tanto quando uma chamada é aceite como quando é rejeitada
- Se existe um endereço de teste ou sandbox. O teste no passo 7 envia um pedido real, por isso quer um sítio seguro para onde o apontar
Construir a automação
1. Acionar no momento que vale a pena reportar
Abra o bloco Start. Selecione HireData como app, depois Conversation como objeto e Ended como trigger. A automação agora corre uma vez de cada vez que uma conversa termina. Qualquer trigger funciona aqui, como uma resposta de formulário concluída ou um candidato atualizado no seu ATS. O trigger só muda quais os campos que tem disponíveis para enviar no passo 4. O resto da receita é igual.2. Adicionar a tarefa HTTP Request
Adicione uma tarefa e selecione HTTP Request. Está arquivada tanto em Add como em Message, e ambos os caminhos abrem a mesma tarefa. Veja onde encontrar a tarefa. Se lhe deram uma especificação ou um comando cURL quando pediu os detalhes do endpoint, clique agora em Import no rodapé do painel e deixe a HireData preencher o pedido. Os dois caminhos preenchem coisas diferentes, por isso verifique o que uma importação preenche e depois releia os passos 3 a 6 comparando com o que foi escrito. Caso contrário, preencha manualmente como abaixo.3. Definir o método e o URL
Uma tarefa nova já tem o método definido comoPOST, que é o que quer. Introduza o endereço do seu endpoint na barra de URL:
4. Construir o corpo JSON a partir de campos da automação
Abra o separador Body e adicione uma propriedade por cada valor que quer enviar. Ao lado de cada Value está um seletor de campos: use-o para escolher um campo do run em vez de escrever um valor fixo, para que cada run envie os seus próprios dados. Os pontos num nome de propriedade aninham-na, por isso um corpo como este precisa de seis propriedades:
Uma conversa agrupa as pessoas nela em Sender, Receiver e Owner, por isso escolha do lado em que o candidato está: o sender quando foi ele a iniciar a conversa, o receiver quando foi a sua automação. Do lado do sender, qual o detalhe de contacto preenchido segue o canal: um número de telefone no WhatsApp, um endereço de email no email.
Mais em geral, os campos que pode escolher dependem do trigger que escolheu no passo 1, e incluem valores que tarefas anteriores na mesma automação produziram. O que chega ao seu endpoint é JSON comum:
5. Autenticar com um bearer token
Abra o separador Auth, selecioneBearer token e cole o token em Token. A HireData envia-o como header Authorization em cada pedido; não há nenhum header para adicionar no separador Headers.
Se o endpoint quer antes uma chave num header nomeado ou num parâmetro de query, ou troca um client ID e um secret por um token, os outros tipos cobrem ambos os casos — veja autenticação.
6. Descrever o que volta
Há duas coisas a fazer antes de a resposta ser utilizável, e é mais fácil por esta ordem. Comece no separador Advanced e escreva uma Description. Para esta tarefa, use “Post conversation outcome”. Ela intitula a tarefa em todo o lado. É também a primeira metade do nome de cada campo que esta tarefa produz, por isso decidi-la agora poupa-lhe reler mais tarde um seletor cheio de campos renomeados. Depois, na secção Response por baixo dos separadores, descreva o corpo que o seu endpoint devolve. Digamos que responde a uma chamada com sucesso com isto:id, com o label “Event ID”, e uma para status, com o label “Status”. As tarefas posteriores podem agora escolher estes dois pelo nome:
Post conversation outcome: idPost conversation outcome: status
id é o que poupa uma tarefa posterior de o escavar desse texto.
Em Error response (non-2xx), descreva o que o endpoint devolve quando rejeita uma chamada. Normalmente é uma mensagem que quereria num log. Essa árvore só vale a pena preencher se configurar o run para continuar depois de uma falha. Veja Decidir o que acontece quando a chamada falha abaixo.
Um valor que não descrever aqui é um valor que nenhuma tarefa posterior pode escolher pelo nome. Veja descrever a resposta.
7. Testar o pedido antes de ativar
Clique em Test no rodapé, e leia o aviso antes de clicar em Send. A caixa de diálogo pede um valor por parâmetro, agrupando-os pelo sítio a que pertencem. O pedido desta receita não tem parâmetros de path nem de query, por isso verá apenas um grupo Body, um input por propriedade do passo 4. Tudo o que definiu como valor fixo no passo 4 já está preenchido. As propriedades que ligou a campos da automação aparecem em branco, porque esses valores só existem durante um run real — escreva um literal plausível em cada uma delas. Veja preencher os valores. Clique em Send. Recebe de volta uma palavra de estado, o código HTTP e quanto tempo a chamada demorou, mais o corpo completo da resposta. Recebe também uma secção Outputs a listar os valores que a HireData extraiu usando a árvore que construiu no passo 6. Leia-os em conjunto. Uma propriedade que descreveu e que volta em falta aparece aqui, e este é o momento mais barato para o descobrir.8. Utilizar um valor da resposta numa tarefa posterior
Adicione uma tarefa depois do HTTP Request que faça algo com o que voltou. Add → Note é a mais simples: coloquePost conversation outcome: id no texto da nota, para que a referência gerada pelo seu próprio sistema fique registada também na HireData.
Qualquer tarefa posterior que receba um valor de texto funciona da mesma forma. O padrão é o que importa: a resposta do endpoint é agora um dado no run, não algo que tenha de ir procurar. Veja utilizar um valor da resposta numa tarefa posterior.
Decidir o que acontece quando a chamada falha
O seu endpoint estará indisponível em algum momento. Dois interruptores no separador Advanced decidem o que isso lhe custa, e para esta receita:- Deixe Fail on error responses ligado. Se o seu endpoint rejeitar o payload, quer que a tarefa o diga.
- Ligue Continue automation on failure apenas se este POST for uma notificação e o resto do run valer a pena sem ele. Se o fizer, preencha também a árvore Error response (non-2xx), para que uma tarefa posterior possa registar o que o seu endpoint realmente disse.
Ativar e verificar os primeiros runs
Ative a automação e deixe uma conversa real terminar. Depois abra Runs e encontre o run. Um HTTP Request concluído mostra a sua descrição como título, com What will you provide? e What will you get back? por baixo, para que possa comparar o que foi enviado com o que configurou. Veja como a tarefa aparece num run e o log de Runs. Verifique os primeiros runs contra os registos do seu próprio sistema antes de confiar na automação. Um pedido que teve sucesso do lado da HireData continua a não lhe dizer nada sobre o que o seu sistema fez com ele.Ainda precisa de ajuda?
Se a automação não está a correr de todo, o problema está no trigger e não no pedido. Veja Porque é que a minha automação não correu?. Se o pedido corre mas volta bloqueado, veja se um pedido voltar bloqueado. Se ainda precisar de ajuda, contacte support@hiredata.com e inclua:- O nome da automação e um link para um run
- O método e o URL da tarefa, com o token removido
- O que esperava que o seu endpoint devolvesse, e o que devolveu em vez disso