Leia os logs de requisições do solvethree quando uma integração falhar

1. 1.

   Abra Logs de requisições

   No console, abra /request-logs. O campo de busca é identificado pelo texto de exemplo: “ID da requisição, site, ação ou erro”. Busque o identificador da tarefa/requisição que você registrou; use o site ou a ação para localizar tentativas relacionadas.

2. 2.

   Comece com Todas

   Mantenha o filtro Todas selecionado ao localizar a requisição. Depois, refine os resultados com Bem-sucedidas, Com falha, Na fila ou Rejeitadas. Começar com um filtro mais restrito pode ocultar a tentativa que você está investigando.

3. 3.

   Confira a data e hora

   As colunas são ID da requisição, Site, Ação, Cobrança, Latência, Horário e Resultado. Compare Horário, Site e Ação com os registros da sua aplicação para não investigar outra tentativa no mesmo destino.

Compare a Latência entre as linhas relevantes para identificar tentativas mais lentas. Mantenha os tempos HTTP da sua aplicação junto desses dados; não presuma que um único valor do console explica todo o atraso observado pelo cliente.

Exportar CSV exporta as linhas filtradas. Defina a busca e os filtros para as tentativas relevantes antes de exportar e revise o arquivo antes de compartilhá-lo.

Os filtros do console descrevem os resultados das requisições/resoluções do serviço. Bem-sucedidas não confirma que o site de destino aceitou seu token. Use a resposta HTTP e o payload da tarefa para identificar qual parte falhou.

A API retornou um status HTTP que não indica sucesso.

Leia o status e a resposta de erro registrados pelo seu cliente. Não trate isso como um payload de tarefa bem-sucedida.

Experimente: Trate primeiro o erro HTTP e corrija o problema informado antes de tentar novamente. Não presuma que toda falha significa crédito insuficiente. Consulte tratamento de erros da API.

A tarefa está pendente ou em resolução.

Esses são status não finais da tarefa, não soluções utilizáveis.

Experimente: Continue consultando essa tarefa até que ela esteja pronta ou com falha. Não crie uma substituta apenas porque uma solução ainda não está disponível.

A tarefa está com falha.

Leia tanto errorCode quanto error. Por exemplo, site-unreachable é um código de erro de tarefa.

Experimente: Pare de consultar essa tarefa e resolva a causa informada antes de outra tentativa. Resoluções com falha são reembolsadas; repetir entradas inválidas sem alterações não vai corrigi-las.

A criação da tarefa excedeu o tempo limite e você não sabe se ela foi concluída.

Guarde qualquer ID de tarefa e o requestId usado na tentativa. Um tempo limite de conexão excedido não comprova que a criação falhou.

Experimente: Recupere a tarefa se você tiver o ID dela. Caso contrário, se você forneceu um requestId, reenvie a mesma solicitação de tarefa com esse ID para recuperar a tarefa existente. Não o reutilize com entradas alteradas; isso gera conflito.

A tarefa está pronta, mas o site rejeita o envio.

Inspecione a requisição enviada ao site. Confirme que ela contém solution.token, e não o ID da tarefa ou um token antigo.

Experimente: Use os valores retornados de userAgent e secChUa com o proxy bem-sucedido e o destino pretendido. Não misture identidades nem troque de proxy entre a resolução e o envio. Um HTTP 403 do destino, por si só, não identifica qual proteção rejeitou a requisição.

Se a causa ainda não estiver clara, entre em contato com [email protected] com informações suficientes para localizar a tentativa e distinguir uma falha do serviço de um envio rejeitado pelo site.

• O ID da tarefa e/ou requestId, o produto e a data e hora com o fuso horário.
• O status HTTP da API ou os campos errorCode e error da tarefa em estado final.
• O hostname de destino e a ação.
• Uma descrição da resposta sem dados sensíveis, informando se ela veio da solvethree ou do site de destino.
• Linhas relevantes dos logs filtrados, se forem úteis, revisadas e sem dados sensíveis antes do envio.

Remova chaves de API, senhas de proxy, tokens, cookies e dados de clientes do relatório e de todos os anexos. O suporte aceita IDs de tarefas/requisições e registros de data e hora sem dados sensíveis; não é necessário fornecer um token bruto para identificar a tentativa.