Closed guisteink closed 1 year ago
Não sei quais foram as conversas sobre isso, mas, será que a melhor opção é mexer em todos os contents mesmo pra isso pra adicionar essa opção?
Será que não seria melhor deixar fora do contents igual o idRef do webhook? Sim, isso valeria pra todos os contents, mas será que realmente vai ter uso do replyTo com múltiplos contents? E se sim, será que é mesmo um problema ele ser usado em todos os contents? Sinto que isso nos contents vai poluir mais API do que limpá-la. Faz sentido o que estou questionando?
Outra coisa, é que uma "boa" prática que tentamos fazer é manter os contents iguais entre os canais, e aqui tá sendo incluso só pro whatsapp, e se for pra manter assim, acho melhor ainda estar fora do contents e manter eles iguais. Foram que nos links de contents (https://zenvia.github.io/zenvia-openapi-spec/v2/#tag/Content-types) não vai aparecer esse campo (a não ser que esses links apontem pro conteúdo de whatspp). Hoje o único content diferente que tem é o text no SMS (na lista de content types tem tanto o text multicanal como o SMS), e não consideramos hoje isso como a melhor das opções.
E seguindo na linha de ficar fora do contents, tem o campo representative (como referência) que só aparece hoje pra Instagram, GBM e Email.
Adicionar idRef no payload de envio: Zenvia APIs | Reference
Referência: Zenvia APIs | Reference