Consulta los registros de solicitudes de solvethree cuando falle una integración

1. 1.

   Abre Registros de solicitudes

   En la consola, abre /request-logs. El campo de búsqueda se identifica por su texto de ejemplo: «ID de solicitud, sitio, acción o error». Busca el identificador de tarea o solicitud que registraste; usa el sitio o la acción para localizar intentos relacionados.

2. 2.

   Empieza por Todos

   Mantén seleccionado el filtro Todos mientras localizas la solicitud. Después, limita los resultados con Correctos, Fallidos, En cola o Rechazados. Empezar con un filtro más restrictivo puede ocultar el intento que investigas.

3. 3.

   Comprueba la marca de tiempo

   Las columnas son ID de solicitud, Sitio, Acción, Facturación, Latencia, Hora y Resultado. Contrasta Hora, Sitio y Acción con los registros de tu aplicación para no investigar otro intento dirigido al mismo destino.

Compara Latencia entre las filas pertinentes para identificar los intentos más lentos. Conserva también los tiempos HTTP de tu aplicación; no supongas que un solo valor de la consola explica toda la demora que observó tu cliente.

Exportar CSV exporta las filas filtradas. Ajusta la búsqueda y los filtros a los intentos pertinentes antes de exportar y revisa el archivo antes de compartirlo.

Los filtros de la consola describen los resultados de las solicitudes y resoluciones del servicio. Correctos no confirma que el sitio web de destino haya aceptado tu token. Usa la respuesta HTTP y los datos de la tarea para identificar qué parte falló.

La API devolvió un estado HTTP que no indica éxito.

Lee el estado y la respuesta de error registrados por tu cliente. No los trates como datos de una tarea completada correctamente.

Prueba esto: Gestiona primero el error HTTP y corrige el problema indicado antes de volver a intentarlo. No supongas que todos los fallos significan que no hay crédito suficiente. Consulta la gestión de errores de la API.

La tarea está pendiente o en resolución.

Estos estados de tarea no son finales ni constituyen soluciones utilizables.

Prueba esto: Sigue consultando esa tarea hasta que esté lista o falle. No crees otra para sustituirla solo porque aún no haya una solución disponible.

La tarea ha fallado.

Lee tanto errorCode como error. Por ejemplo, site-unreachable es un código de error de tarea.

Prueba esto: Deja de consultar esa tarea y resuelve la causa indicada antes de hacer otro intento. Las resoluciones fallidas se reembolsan; repetir los mismos datos de entrada no válidos no los corregirá.

Se agotó el tiempo de espera al crear la tarea y no sabes si se creó correctamente.

Conserva cualquier ID de tarea y el requestId utilizado en el intento. Que se agote el tiempo de espera de la conexión no demuestra que la creación haya fallado.

Prueba esto: Recupera la tarea si tienes su ID. De lo contrario, si proporcionaste un requestId, vuelve a enviar la misma solicitud de tarea con ese ID para recuperar la tarea existente. No lo reutilices con datos de entrada modificados; eso genera un conflicto.

La tarea está lista, pero el sitio web rechaza el envío.

Inspecciona la solicitud saliente al sitio web. Confirma que contiene solution.token y no el ID de la tarea ni un token anterior.

Prueba esto: Usa los valores userAgent y secChUa devueltos con el proxy que tuvo éxito y el destino previsto. No mezcles identidades ni cambies de proxy entre la resolución y el envío. Un HTTP 403 del destino, por sí solo, no identifica qué protección rechazó la solicitud.

Si la causa sigue sin estar clara, escribe a [email protected] con información suficiente para localizar el intento y distinguir un fallo del servicio de un envío rechazado por el sitio web.

• El ID de la tarea y/o requestId, el producto y la marca de tiempo con su zona horaria.
• El estado HTTP de la API, o errorCode y error de la tarea en su estado final.
• El nombre de host de destino y la acción.
• Una descripción de la respuesta sin información confidencial, que indique si procede de solvethree o del sitio web de destino.
• Las filas filtradas pertinentes del registro, si resultan útiles, revisadas y sin información confidencial antes de enviarlas.

Elimina las claves de API, las contraseñas de proxy, los tokens, las cookies y los datos de clientes del informe y de cualquier archivo adjunto. Soporte acepta ID de tarea o solicitud y marcas de tiempo depurados de información confidencial; no hace falta un token sin procesar para identificar el intento.