[Dúvida] Sobre parâmetros inicio e fim no endpoint GET /webhook

[renatofrota]

Entendo que cada chave só pode ter 1 webhook associado por vez.

A existência dos parâmetros inicio e fim no endpoint GET /webhook me faz entender que há uma necessidade por parte do PSP de registrar o histórico de webhooks já associados a cada chave, ou seja, as datas de cadastramento e descadastramento (remoção/substituição por outra). É isso mesmo?

[rubenskuhl]

Eu acho que essa consulta por /webhook sem chave não faz muito sentido.

[renatofrota]

Também acho.

Inclusive o retorno da consulta não esclarece nada com nada (como em qual chave o webhook foi cadastrado), exceto uma possível lista de webhooks.

Deve ser mero resquício anterior à decisão de atender o pedido que fiz em #62 de tornar os webhooks vinculados à chaves e não aos client_id (e vários concordaram comigo):

seria interessante que o QR Code utilizado para realizar as cobranças (ou a chave que está vinculada a ele) tivesse um webhook vinculado

Será essencial para a maioria das pessoas que querem, efetivamente, adotar o Pix como meio principal de pagamento em seus estabelecimentos comerciais, receber as notificações de pagamento (e poder escolher o endereço de forma simplificada). Isso poderia estar vinculado à própria chave, no meu ponto de vista. Recebeu um Pix na chave X -> manda uma notificação no webhook dela.

etc...

e atendido no #120, já às vésperas do Go Live 🥳

[ninrod]

Entendo que cada chave só pode ter 1 webhook associado por vez.

A existência dos parâmetros inicio e fim no endpoint GET /webhook me faz entender que há uma necessidade por parte do PSP de registrar o histórico de webhooks já associados a cada chave, ou seja, as datas de cadastramento e descadastramento (remoção/substituição por outra). É isso mesmo?

A ideia aqui era só "seguir o padrão" e prover um local onde se possa verificar "onde estão os meus webhooks, e como estão configurados neste momento".

Talvez o "inicio" e "fim" estejam sobrando, mas a ideia aqui era possibilitar alguma espécie de filtro para casos em que houvesse muitos webhooks, por exemplo.

Dito isto, continua sendo um problema?

[renatofrota]

Entendo que cada chave só pode ter 1 webhook associado por vez.

A existência dos parâmetros inicio e fim no endpoint GET /webhook me faz entender que há uma necessidade por parte do PSP de registrar o histórico de webhooks já associados a cada chave, ou seja, as datas de cadastramento e descadastramento (remoção/substituição por outra). É isso mesmo?

A ideia aqui era só "seguir o padrão" e prover um local onde se possa verificar "onde estão os meus webhooks, e como estão configurados neste momento".

Talvez o "inicio" e "fim" estejam sobrando, mas a ideia aqui era possibilitar alguma espécie de filtro para casos em que houvesse muitos webhooks, por exemplo.

Dito isto, continua sendo um problema?

Claro que não. Sem a exigência de inicio e fim e retornando todos os webhooks ativos no momento da consulta (com identificação de qual chave se refere cada um deles), não apenas faria total sentido como seria muito útil, na minha opinião.

[rubenskuhl]

Entendo que cada chave só pode ter 1 webhook associado por vez.

A existência dos parâmetros inicio e fim no endpoint GET /webhook me faz entender que há uma necessidade por parte do PSP de registrar o histórico de webhooks já associados a cada chave, ou seja, as datas de cadastramento e descadastramento (remoção/substituição por outra). É isso mesmo?

A ideia aqui era só "seguir o padrão" e prover um local onde se possa verificar "onde estão os meus webhooks, e como estão configurados neste momento".

Mas seria necessário mostrar a que chaves eles se referenciam, não ? Como está parece estar mostrando apenas quais são e não a que chaves se referem.

Talvez o "inicio" e "fim" estejam sobrando, mas a ideia aqui era possibilitar alguma espécie de filtro para casos em que houvesse muitos webhooks, por exemplo.

O máximo de chaves por CNPJ já é 20...

Dito isto, continua sendo um problema?

Talvez o pessoal dos PSPs possam comentar se implementarem de fato isso com inicio/fim... pois isso é bastante oneroso em requerer armazenamento de histórico, não apenas de situação operacional atual.

[renatofrota]

O máximo de chaves por CNPJ já é 20...

E não é mais fácil consultar 1x todos os webhook (retornados em um array com pares de chave/URL) do que enviar 1 consulta para cada chave (sendo então, até 20 consultas)?

Dito isto, continua sendo um problema?

Talvez o pessoal dos PSPs possam comentar se implementarem de fato isso com inicio/fim... pois isso é bastante oneroso em requerer armazenamento de histórico, não apenas de situação operacional atual.

Pelo que eu entendi, o @ninrod disse que os parâmetros estão mesmo "sobrando" na documentação (e sem eles, o histórico não seria necessário para atender às consultas, os dados retornados seriam sempre os atuais ao momento da consulta).

[rubenskuhl]

O máximo de chaves por CNPJ já é 20...

E não é mais fácil consultar 1x todos os webhook (retornados em um array com pares de chave/URL) do que enviar 1 consulta para cada chave (sendo então, até 20 consultas)?

Sim, é mais fácil e meus únicos pontos são remover o início/fim e na consulta mostrar pares chave/URL e não apenas URL.

Dito isto, continua sendo um problema?

Talvez o pessoal dos PSPs possam comentar se implementarem de fato isso com inicio/fim... pois isso é bastante oneroso em requerer armazenamento de histórico, não apenas de situação operacional atual.

Pelo que eu entendi, o @ninrod disse que os parâmetros estão mesmo "sobrando" na documentação (e sem eles, o histórico não seria necessário para atender às consultas, os dados retornados seriam sempre os atuais ao momento da consulta).

Remover o início/fim é sim interessante.

[renatofrota]

E não é mais fácil consultar 1x todos os webhook (retornados em um array com pares de chave/URL) do que enviar 1 consulta para cada chave (sendo então, até 20 consultas)?

Sim, é mais fácil e meus únicos pontos são remover o início/fim e na consulta mostrar pares chave/URL e não apenas URL.

Por alguma razão, eu tinha interpretado errado essa parte anteriormente. Acho que era fome. Agora que estou bem alimentado, concordamos, então. 😁

[ninrod]

Mas seria necessário mostrar a que chaves eles se referenciam, não ? Como está parece estar mostrando apenas quais são e não a que chaves se referem.

Tem razão. De fato. Há esse gap no objeto de retorno.

O máximo de chaves por CNPJ já é 20...

De fato. Como o client_id está ligado a um CNPJ, há um limite máximo (definido fora da API) de webhooks a serem configurados. Não faz sentido "inicio" e "fim" nesse contexto. Muito bem apontado.

Remover o início/fim é sim interessante.

Também acho e já estou convencido. Um problema bem grande, entretanto, é a preocupação de "não quebrar" os clientes e as implementações. Acredito que remover estes parâmetros seria uma "quebra". Ou não?

[rubenskuhl]

Mas seria necessário mostrar a que chaves eles se referenciam, não ? Como está parece estar mostrando apenas quais são e não a que chaves se referem.

Tem razão. De fato. Há esse gap no objeto de retorno.

O máximo de chaves por CNPJ já é 20...

De fato. Como o client_id está ligado a um CNPJ, há um limite máximo (definido fora da API) de webhooks a serem configurados. Não faz sentido "inicio" e "fim" nesse contexto. Muito bem apontado.

Remover o início/fim é sim interessante.

Também acho e já estou convencido. Um problema bem grande, entretanto, é a preocupação de "não quebrar" os clientes e as implementações. Acredito que remover estes parâmetros seria uma "quebra". Ou não?

Meu feeling/chute/especulação é que os PSPs não implementaram e os ECs não usaram essa chamada específica... mas a API pode especificar que se os campos inicio/fim opcionais forem especificados, devem ser ignorados.

[ninrod]

Meu feeling/chute/especulação é que os PSPs não implementaram e os ECs não usaram essa chamada específica... mas a API pode especificar que se os campos inicio/fim opcionais forem especificados, devem ser ignorados.

Certo, uma boa saída para inclusão em uma eventual 2.2.1.

[ninrod]

Sim, é mais fácil e meus únicos pontos são remover o início/fim e na consulta mostrar pares chave/URL e não apenas URL.

Plenamente de acordo. Temos apenas que ver como faríamos essa adição sem quebrar as implementações. Talvez começar agregando a chave como opcional, de saída, para não quebrar implementações.

[ninrod]

@rubenskuhl ,

Mas seria necessário mostrar a que chaves eles se referenciam, não ? Como está parece estar mostrando apenas quais são e não a que chaves se referem.

O schema define que deve ser mostrado a que chaves os webhooks se referem. Me confundi olhando o exemplo quebrado pelo redoc-li. O schema está correto:

[ninrod]

Você deve ter olhado o exemplo, que está quebrado pelo redoc-cli (o $href é sinal da quebra)

[renatofrota]

@ninrod

Em relação a 2.2.1-rc0: os parâmetros inicio e fim passaram a ser opcionais. Tem alguma menção a eles serem ignorados pelo PSP, se presentes na consulta? Isso permitiria os PSPs deixarem de guardar histórico acerca dos cadastramentos de webhooks.

[ninrod]

Tem alguma menção a eles serem ignorados pelo PSP, se presentes na consulta? Isso permitiria os PSPs deixarem de guardar histórico acerca dos cadastramentos de webhooks.

Não dizemos categoricamente que ele deve ser ignorado, não negociei isso para essa release (inclusive tem a ideia de colocar como deprecated para ficar categoricamente nítido que esse campo vai sair, etc...) Só consegui deixá-lo como opcional, por agora.