Histórico de mensagens em sugestões

discordo. um EC pode querer omitir essa informação para o seu time de dev (se tiver tarifa negociada)

<@!793123559874494465>, minha sugestão é não perguntar da tarifa e já incluí-la, porque, do outro lado, usa quem quiser.

não consegui pensar em mais nada que possa ser relevante, por hora

Esse ponto é interessante, essas configurações serão em algum momento disponibilizadas na interface humana, até as nossas interfaces consumem o core dos endpoints, assim, oferecermos os endpoint's, quando já prontos, é uma forma de vocês desenvolvedores já terem acesso as soluções. O próprio Postman ajudaria nesses consumos.

Perceberão em outros momentos soluções chegarem primeiro na API, também é uma forma do time da Engenharia da API ter maior liberdade/agilidade em atendê-los.

Até então estamos assim:

PUT /gn/config

as credenciais podem ter escopo de autorização diferentes. um conjunto de client_id / client_secret específico poderia ter acesso ao endpoint /gn/config

Só esclarecendo meu ponto de vista: criar um end-point pra configurar é o mesmo que fornecer direitos administrativos para qualquer desenvolvedor da aplicação que consome o end-point (incluindo o direito de delegar esse direito para usuários da aplicação). Essa funcionalidade no painel, restringe o acesso aos usuários do painel, com identificação e rastreabilidade das alterações.

inclusive a validação por regex, que numa UI poderia ter opções do tipo:
- "não validar regex (aceitar qualquer transação)" equivalente a .;
- "não aceitar recebimentos sem txid" equivalente a .+;
- "validar com o seguinte regex:" que abriria um campo pra fornecer o regex a ser testado

checkbox ou slides liga/desliga pra alterar cada opção seriam mais que suficientes

eu também acho que essas configurações ficariam melhores no painel (ou até nos apps). uma vez definidas, alterações seriam raras.

<@!793123559874494465>, a existência dessa interface não elimina uma interface humana pra essas configurações, correto? (essa interface poderia, inclusive, desabilitar esse end-point). Uma UI autenticada, auditável, na aplicação de vocês me parece uma solução mais interessante para configurações que alteram significativamente o comportamento da solução.

total sentido. especialmente o regex. podem ser diferentes por chaves (posso exigir txid numa chave e ter outra chave que aceita pagamento sem txid para conciliação manual)

Em resumo, como está a discussão <@!793123559874494465> ?

Hum, interessante esse ponto, colocar por chave. Pode ser que na chave X eu queira receber notificação, e na Y não. Faz sentido?

Se for por cada chave (Webhook nesse caso) seria interessante colocar no singular. Mas se for algo pra todas os Webhooks eu deixaria no plural

Uma outro ponto seria colocar isso por chave não?

ou fica estranho?

eu também padronizaria tudo pro singular. webhook, tarifa, recebimento

Em relação a isso já que implementaram também o envio do Pix e ele é async, seria interessante criar um webhook também pra recusa do PSP recebedor...

Porque a ideia com a aplicação do /gn/ é não quebrar, por exemplo nessa /config. E aplicar isso no envio do pix também seria show.