Histórico de mensagens sobre url

Não, na API Pix a URL é definida para chave Pix. E o que você tem para dar match são chave e txid.

Boa tarde. Fiz tudo que foi instruido porem retorna o erro abaixo ao cadastrar o webhook
{
"nome": "webhook_invalido",
"mensagem": "A URL informada respondeu com o código HTTP 403"
}

Boa tarde <@!775350441965649951>
Sou o Diogo trabalho com o Patrick da AEnet, Dias atrás ele estava testando a emissão de boleto via SDK e constatou que vários boletos eram emitidos sem controle.
Então ele decidiu utilizar os endpoints para emissão sem o SDK.
Ele me informou que você está a par da situação.
Porém hoje constatamos que mesmo utilizando o CURL direto para cada chamada são gerados 2 boletos
Não há looping no nosso código
Apenas uma chamada CURL para recuperar o Token e uma outra chamada CURL para geração do boleto utilizando o Token
Pode nos ajudar?

A autenticação de TLS mútuo não está configurada na URL informada

Tbm existe um outro erro a parte, ao entrar para visualizar um ticket, tem um erro estourando no console, varias e varias vezes, aparentemente tem uma recursividade....

Ex da url:
https://sistema.gerencianet.com.br/tickets/historico/todos/___ID_AQUI_DO_TICKET

Ocorre esse fato, porque cada aplicação deve possuir uma url única. No Fortunus voce define a mesma url, na nova API, apesar de possuir o mesmo domínio, o sistema do Mk-Auth insere de forma automática um parâmetro no final que diferencia as urls. Por isso, o ideal é você criar uma aplicação da nova API.

troquei a url e o certificado

Bom dia, estou tentando configurar o webhook de uma aplicação node no IIS, mas sempre é retornada a mensagem -> "A URL informada respondeu com o código HTTP 401"

Você não poderia enviar o link dessa página com o botão pelo whatsapp, ao invés de enviar o copia e cola? Essa parte do copia e cola que sai como link seria a url do payload, então o Whatsapp considera como sendo um link.

É enviada via URL de notificação do boleto.

alguma opção de url que adiciona o header Content-Disposition: attachment;

Bom dia <@!609024392864989184> ! Nesse caso não, porque a url deve ser única por aplicação. Então o certo é enviar na requisição de emissão o atributo metadata contendo o notification_url.

consigo cadastrar uma URL de notificação para a conta em vez de ter que especificar em todo boleto que é criado?

fiz um teste de um pagamento e passei minha url pra receber o webhook de vcs

Sim, sei disso, na verdade deu certo através de uma gambiarra utilizando o proxy do Api gateway, mas o resultado não foi muito bom, porque meio que o URL so fica sendo validado pra a gerencia net e aberto para o publico

Boa tarde! quanto as notification, estou recebendo-as em uma url post normalmente, e está sendo exibido no console.log "Em Node", a minha dúvida é: como extrair esses dados para salvar no banco de dados apartir do token recebido?

Então, Pedro.
Por ser uma configuração de servidor específica e característica da hospedagem da AWS não conseguimos muitos detalhes neste quesito.
Em casos de clientes que utilizam este ambiente conseguiram solucionar criando um subdomínio e o apontando para uma API Gateway, depois realizando as configurações de mTLS seguindo os passos do seguinte tutorial, enviado também pelo Rubens.
https://aws.amazon.com/pt/blogs/compute/introducing-mutual-tls-authentication-for-amazon-api-gateway/

Tendo realizado esta configuração conseguimos averiguar se a URL foi registrada com sucesso, e se está sendo enviada as notificações corretamente.

curl_setopt_array($curl, array(
CURLOPT_URL => "https://api-pix.gerencianet.com.br/v2/webhook/" . $chave, // Rota base, homologaço ou produço
CURLOPT_RETURNTRANSFER => true,
CURLOPT_ENCODING => "",
CURLOPT_MAXREDIRS => 10,
CURLOPT_TIMEOUT => 0,
CURLOPT_FOLLOWLOCATION => true,
CURLOPT_HTTP_VERSION => CURL_HTTP_VERSION_1_1,
CURLOPT_CUSTOMREQUEST => "PUT",
CURLOPT_POSTFIELDS => $json,
CURLOPT_SSLCERT => $config["certificado"], // Caminho do certificado
CURLOPT_SSLCERTPASSWD => "",
CURLOPT_HTTPHEADER => array(
"Content-Type: application/json",
"authorization: Bearer " . $access_token,
"x-skip-mtls-checking: false"
),
));

$response = curl_exec($curl);

Retorna a seguinte mensagem:
{
"nome": "webhook_invalido",
"mensagem": "A autenticação de TLS mútuo não está configurada na URL informada"
}

O Sucuri aceita mTLS ? E essa URL não parece ser a do webhook, pois não está com exigência de client-certificate.