Listar respostas do Flow

Os formulários que os clientes enviaram para UM Flow, os mais novos primeiro. O Flow é resolvido primeiro dentro da WABA da própria chave, e essa resolução é a única coisa que escopa o resto — um Flow de outra WABA (inclusive outra WABA do mesmo tenant) responde 404 e nenhuma resposta chega a ser lida.

Respostas fora da janela de retenção são excluídas AQUI, não só pela tarefa de poda, para que ninguém leia um envio que a janela publicada diz ter sumido. contactPhone vem null quando o telefone já não é nosso para publicar. externalMessageId é o wamid da Meta e é NOMEADO como id de provedor de propósito — todo outro id desta superfície é local.

notice: "FLOW_RESPONSES_WINDOW_TRUNCATED" aparece na página quando o Flow cunhou mais envios do que uma requisição correlaciona (teto de 10.000 sessões). Uma resposta curta que não diz que é curta é o que faz o cliente concluir que perdeu envios. Permissão flows:read.

Exige chave com escopo de número. Uma chave de tenant precisa nomear o número no header x-whatsapp-number-id, senão recebe 403 TENANT_SCOPE_NOT_ALLOWED.

media[] leva os arquivos que a pessoa ANEXOU dentro do formulário (PhotoPicker / DocumentPicker). Eles NÃO estão em response: um picker exige data_exchange, portanto as referências chegam no pedido que o nosso endpoint decifra — uma troca HTTP diferente do nfm_reply que produziu a linha — e este array é a cópia re-hospedada, ligada pelo flowToken. É o único lugar onde um chamador alcança os bytes: a Meta apaga o original após 20 dias. É SEMPRE um array, [] quando nada foi anexado. url é um link estável nosso e está presente assim que a linha existe, INCLUSIVE enquanto status for "PENDING". Buscá-lo antes de a re-hospedagem terminar não dá 404: a rota segura o pedido enquanto espera pelo arquivo e então o serve, toda busca posterior é um redirect, e uma espera que estoura responde 404 com o cabeçalho Retry-After. O valor não muda depois de os bytes chegarem, portanto é seguro guardá-lo logo na chegada, e o status (PENDING/STORED/FAILED) continua sendo como o chamador sabe se eles chegaram. É a ordem que justifica esse link: o evento é emitido assim que o envio é guardado e a re-hospedagem roda depois dele, portanto o anúncio precede normalmente os bytes. url só é nulo quando a instalação não tem segredo de assinatura configurado (aí volta ao comportamento antigo, a URL direta do objeto assim que ficar STORED), quando a Meta não enviou media_id para assinar uma identidade em cima, ou num número RELAY_ONLY onde nada foi guardado — nunca apenas porque a transferência ainda não terminou. Trate-o como opaco: busque, nunca construa um. mimeType é farejado dos bytes decifrados e nunca do nome do arquivo, e ele e sizeBytes são null até o arquivo ficar guardado. Nem cdn_url nem material de cifra são alguma vez publicados.

submitted[] é o que a pessoa de fato ESCREVEU, tela a tela. ⛔ Num Flow data_exchange é o ÚNICO lugar onde essas respostas existem: ali o response é o nfm_reply da Meta, um envelope que leva o flow_token e mais nada — quem abre o response num Flow desses encontra uma sala vazia e conclui que o envio se perdeu. Num Flow SIMPLES, sem endpoint, as respostas CHEGAM no response e o submitted vem [].

Cada entrada é um pedido data_exchange que a META NOS ENVIOU: screen (a tela em que a pessoa estava, ou null), at (ISO 8601), data (o objeto já parseado) e omitted. Nunca é o que o SEU endpoint respondeu — o extension_message_response não é publicado em lugar nenhum do Pilot Status. E só as trocas data_exchange são capturadas: o INIT devolve o estado que NÓS semeamos quando o Flow foi enviado, e o BACK é navegação, portanto esta lista é legitimamente MAIS CURTA do que o tráfego que o seu próprio endpoint viu. Essa diferença não é perda.

NESTE endpoint o submitted é sempre um array e nunca null — [] tanto quando não há nada como quando o número não guarda conteúdo de cliente, porque “nada foi capturado” e “não conseguimos olhar” seriam senão o mesmo valor. (No webhook flow.response_received é o contrário, null e nunca [], porque lá o redator só apaga um campo que tenha algo dentro.) Nada é truncado em silêncio: ou a entrada leva data com omitted: null, ou leva data: null e diz o PORQUÊ. DATA_TOO_LARGE é uma troca grande demais, que mantém a linha e o lugar dela na sequência — o teto que ela passou conta-se em BYTES, não em caracteres, portanto texto com acentos chega lá antes do que o comprimento sugere. LIMIT_REACHED é o teto de 50 trocas por formulário: uma entrada final de marcação, e nada depois dela ficou guardado. UNREADABLE é uma troca que ficou guardada mas cujo conteúdo não se conseguiu reler. Não há terceira forma.

A lista só cresce e nunca é de-duplicada: quem volta atrás numa tela e responde de novo produz uma segunda entrada GENUÍNA, e é o at que distingue duas passagens debaixo do mesmo flowToken. As trocas ficam 30 dias + 1 — um dia a MAIS do que a linha da resposta — porque a troca é capturada enquanto a pessoa ainda está preenchendo, minutos ANTES do envio que cria a linha; com uma janela igual elas expirariam primeiro, e uma resposta ainda dentro da retenção dela publicaria submitted: [] nos seus últimos minutos. Num número com piiMode: "RELAY_ONLY" não fica aqui nada: nem uma entrada ocultada, nenhuma entrada.