Errores
Códigos de estado y forma de error comunes de Open API.
errores
Los errores abiertos API utilizan cuerpos de respuesta JSON cuando la solicitud llega a la capa API. Es posible que las fallas de red, las fallas de CDN y las interrupciones de respuesta binaria no tengan esta forma exacta, por lo que su cliente debe manejar tanto los errores estructurados API como los errores de transporte.
Cada punto final utiliza el mismo contexto de autenticación de portador:
Authorization: Bearer KITTA_API_KEY{
"code": "invalid_request",
"message": "The request payload is invalid.",
"requestId": "req_xxx"
}Códigos de estado
| Estado | Significado | Acción típica |
|---|---|---|
400 | Cuerpo de solicitud, parámetro de ruta, parámetro de consulta o URL de medios no válidos | Corrija la solicitud antes de volver a intentarlo |
401 | Clave API faltante, mal formada, revocada o deshabilitada | Detener reintentos y actualizar credenciales |
402 | Créditos insuficientes, cuota API o asignación de proveedores | Detener el lote y mostrar el estado de facturación |
404 | La identificación del recurso es desconocida para la cuenta autenticada | Actualizar registros locales |
409 | El recurso está en un estado que entra en conflicto con la operación | Esperar o eliminar dependencias |
422 | Se aceptaron medios pero no se pueden procesar | Pregunte por diferentes medios de entrada |
429 | Límite de tarifa excedido | Reintentar con retroceso exponencial |
500 | Error del servidor | Vuelva a intentarlo un pequeño número de veces y registre requestId |
Solicitar registro
Registre el punto final, el método HTTP, el estado, code, requestId y su propia identificación de trabajo interna. No registre claves de portador API, texto de usuario completo ni URL de medios privados a menos que su política de privacidad y su flujo de trabajo de soporte lo permitan explícitamente.
Para puntos finales asíncronos, incluya tanto la identificación de la tarea API como la identificación de su base de datos interna en los registros. Eso hace posible conciliar reintentos sin crear trabajo duplicado.
Facturación y créditos
No todos los errores tienen el mismo significado de facturación. Los fallos de validación normalmente ocurren antes de que comience el trabajo con los medios. Pueden ocurrir fallas de procesamiento después de que se aceptó una tarea. Para preguntas de facturación de cara al usuario, compare el estado de la tarea con una nueva lectura de Perfil en lugar de inferir el costo únicamente del estado de HTTP.
Política de reintento
Vuelva a intentar 429 y algunas respuestas de 500 con retroceso. No vuelva a intentar ciegamente 400, 401 o 402; aquellos requieren cambios de solicitud, credencial o facturación. Para crear puntos finales, conserve la identificación devuelta antes de volver a intentar cualquier operación de seguimiento.