Try Catch em requisição

Gabriel,
Neste caso, acredito que seria mais fácil você padronizar o retorno do Json.
Ex. Quando vem do retorno da API +5567999990000 altere ele para o 559999900000 e o numero que vc quer comparar coloque ele também no mesmo formato. Caso ele não tenha o 55, adicione e compare.
Espero ter ajudado,

Mas então, eu uso o telefone justamente para encontrar o usuário, quero modificar a variável de entrada DA TAKE/WPP, por exemplo, a pessoa fala comigo com um telefone 5199999999 se não der eu mudo pra 55519999999 se não der mudo pra +5551999999999, pois na base da hubspot existem as 3 formas registradas e preciso de um exact match pra ter retorno

Então, minha sugestão seria você criar 3 chamadas HTTPs no mesmo bloco(se o retorno não for muito lento), crie uma variável que controle o retorno nas chamadas, caso encontre, preencha como 1 senão 0. Na 2ª e na 3ª crie uma condição para requisição HTTP, que se for encontrado 1 na variável de controle, as requisições não executem.

Também pode criar um bloco com a chamada HTTP e o preenchimento da variável de controle e um bloco com uma condição de saída que verifica, se a variável for 0, voltar para o bloco que efetua a requisição, alterando o numero de telefone para cada chamada. Porem tome cuidado para não cair em um loop. Para isso não acontecer, criei um variável de contagem e no segundo bloco direcione o fluxo para outro bloco quando chegar em 5 por exemplo.

foi exatamente o que eu fiz, mas seria bom poder resolver tudo em 1 célula só. Gostaria de ter mais controle e liberdade na operação, se pudesse injetar mais códigos(em mais etapas) seria mais fácil

Olá @Gabriel_Viero

Uma dúvida sobre sua pergunta: em sua integração com Hubspot, foi uma decisão realizar de implementação utilizar a verificação pelo número de celular?

• como aqui usamos o Hubspot, por vezes, esbarramos em diferentes padrões de registros de um número como +5531988776655, 5531988776655, 31988776655, (31) 98877-6655 etc., que exigiria requisições adicionais como sugerido pelo @Leandro_Silva e, às vezes, até script

👉 A minha sugestão seria refletir sobre o uso deste valor para verificar se aquele contato está (ou não) no Hubspot, pela quantidade de tratativas que seriam feitas. Assim, pode ser feito 2 requisições para tentar simplificar e atualizar sua base de dados no CRM Hubspot

• a primeira requisição utilizando o padrão normalmente trazido na plataforma, ou seja, DDI+DDD+Numero (por exemplo, 5531988776655). Se caso a requisição retornasse indicando que aquele contato não existe / não está cadastrado, então
• a segunda requisição seria, a partir da solicitação do e-mail de contato deste usuário no fluxo, realizar esta requisição e, ela retornando que existe, seguiria seu fluxo, além de poder fazer uma terceira requisição para atualizar o número de telefone do contato cujo o e-mail informado está associado. Em próximas interações, somente a primeira requisição seria suficiente (além de atualizar as informações)

Émeio frustrante receber a culpa por uma limitação na plataforma, peço que repense seu atendimento, eu vim com um problema de otimização, já havia resolvido antes de responderem a pergunta(conforme informado) e tá tudo certo, aponto que seria bom uma forma de fazer try catch ou testes mais elaborados em 1 mesma célula, apenas, e em vez de reconhecer a limitação da plataforma você me diz para repensar o que estou fazendo? No mínimo complicado, sabe? Não que eu deva justificar as escolhas de negócio em nossa operação mas essa é, sim, a melhor maneira de fazer a validação no ponto em que é necessária.

Tenha um bom dia.

Abs

Ei @Gabriel_Viero, tudo bem?

Certeza que o @Romulo_Rafael fez só uma provocação para tentar ajudar e, caso você considere importante, quem sabe possa aplicar. De forma alguma quis invalidar sua solução e escolhas, até porque você conhece a realidade do seu negócio mais do que qualquer um de nós, certo? Peço desculpas se passou uma impressão errada.

Sobre sua sugestão acima, pode deixar que vou passar ao time responsável. O Blip é um produto que tá sempre em evolução e o feedback dos blippers é muito importante pra gente, viu? Valeu por compartilhar.

Novamente o problema posto para o cliente, o erro foi minha interpretação? Seguinte, eu informei, na segunda mensagem, que havia resolvido o problema, e apenas queria uma solução menos “go horse” em uma célula só, a resposta que esperava era um simples “não, nossa ferramenta não possui a funcionalidade de um teste com múltiplos fatores no momento”, entendo sugerirem uma outra via, mas eu insisti que só me interessaria por uma solução mais enxuta e vem outro agente me dizer para refletir sobre meu negócio, achei pedante, em nenhum momento se admitiu a limitação da ferramenta(o que é ok absolutamente todas as ferramentas têm e não diminui as muitas qualidades da Take) mas a dificuldade em assumir isso e jogar o problema de volta pra mim me deixou, sinceramente, desgostoso. Entendo que não deve ter sido a intenção de ninguém ser pedante, mas peço que as justificativas para isso sejam tratadas de maneira interna, a resposta para minha pergunta era um simples “não conseguimos te ajudar da forma que precisas” e estaria tudo bem. Efnim, podemos dar como encerrado, se quiserem que eu compartihe minha solução com vocês(que foi melhor otimizada que as sugestões) fico disponível

Abs.

Por favor. Acredito que vai ajudar outras pessoas que possam estar passando pelo mesmo.
Valeu, @Gabriel_Viero.