Cuando una petición falla, empieza por el código HTTP y el mensaje que acompaña a la respuesta. No todos los errores se solucionan esperando: algunos requieren corregir la solicitud o revisar el acceso.

Identifica la categoría

Del código a la acción

Tres acciones distintas

400 · 401 · 402 · 422

Corrige el formato, los parámetros, la clave o el saldo según el mensaje. No repitas sin revisar la causa.

429

Reduce el ritmo o la concurrencia. Revisa las solicitudes activas de la cuenta y limita los reintentos.

500 · 503

Considera una espera y un reintento limitado. Comprueba primero si el proceso ya modificó datos.

El estado oficial del servicio se consulta en otra web. Este resumen no muestra una monitorización en directo.

Este resumen se basa en los códigos oficiales de DeepSeek:

Código Significado Primera revisión
400 Formato de solicitud inválido Comprueba el cuerpo enviado.
401 Autenticación fallida Revisa la clave API.
402 Saldo insuficiente Consulta el saldo de la plataforma.
422 Parámetros inválidos Revisa los campos indicados por el error.
429 Límite alcanzado Reduce la concurrencia y el ritmo de solicitudes.
500 Error del servidor Espera antes de reintentar.
503 Servidor sobrecargado Espera antes de reintentar.

Reduce la petición para encontrar el fallo

Compara tu solicitud con una petición básica que puedas revisar con facilidad. Retira temporalmente opciones añadidas y conserva solo la tarea necesaria. Cambia una condición cada vez y registra si el error se mantiene.

Comprueba el JSON que sale de tu aplicación, no solo el objeto que crees haber construido. Una biblioteca intermedia puede añadir parámetros, transformar campos o reutilizar una configuración anterior. Utiliza registros que oculten credenciales y sustituyan el contenido privado por un ejemplo ficticio.

Cómo enfocar un error 429

La documentación de concurrencia aclara que los límites se calculan por cuenta y que una petición cuenta hasta que termina la respuesta. Crear otra clave de la misma cuenta no proporciona por sí solo un límite independiente.

Como diseño de aplicación, utiliza una cola y un número controlado de trabajos simultáneos. Reserva un margen para peticiones lentas. Si varias tareas fallan a la vez, evita que todas se reintenten en el mismo instante: reparte los intentos y establece un máximo.

Cuándo reintentar

Para fallos temporales, define esperas crecientes y una condición de parada. Es una recomendación de implementación, no una garantía de recuperación. Antes de repetir un proceso que también modifica datos, comprueba qué pasos ya terminaron para no duplicar acciones.

En errores de formato, parámetros, clave o saldo, corrige primero la causa identificada. Repetir la misma solicitud sin cambios no ayuda a diagnosticarla.

Qué guardar para pedir ayuda

  • Fecha y hora, con zona horaria.
  • Modelo, endpoint y versión de la biblioteca utilizada.
  • Código HTTP y mensaje de error sin credenciales.
  • Ejemplo mínimo que reproduce el problema.
  • Frecuencia del fallo y cambios recientes en la aplicación.

Consulta también el estado oficial del servicio. Si la integración vuelve a funcionar, revisa las tareas pendientes antes de reanudar el volumen completo. La guía de costes te ayuda a contemplar peticiones repetidas en el presupuesto.

Documentación oficial consultada el 12 de septiembre de 2026. DEspañol es una publicación independiente; los ejemplos son educativos y no se han ejecutado contra la API.