Recuperación de información
Recuperación de información
Esta sección proporciona los endpoints de la API y las estructuras de datos para recuperar información sobre tus Imports, Files y Documents. Para actualizaciones en tiempo real del estado de procesamiento, usa webhooks en lugar de hacer polling a estos endpoints.
Cuándo usar estas APIs:
- Sincronización inicial con el estado actual
- Recuperación tras eventos de webhook perdidos
- Comprobación masiva de estados para dashboards
- Recuperación de estructuras y metadatos detallados de las entidades
Import API
Recupera información sobre tus operaciones de importación mediante nuestra API REST.
Listar Imports: GET /v1/ingest/imports/
Obtener un Import: GET /v1/ingest/imports/{id}
Estructura de Import
Notas:
- Import devuelve una lista de todos los archivos, incluidos los ZIP y su contenido extraído
- El campo
documentsindica el total de documentos extraídos en todos los archivos - El campo
channelindica cómo se creó el import (API, subida web o email) - Cada archivo del array
filessigue la estructura de File documentada abajo - Los archivos comprimidos (ZIP) tienen
compressed: truey normalmente un arraydocumentIdsvacío - Los archivos extraídos de un ZIP incluyen
parentFileId, que referencia al archivo comprimido original clientDatacontiene los metadatos personalizados aportados durante la subida (objeto vacío si no hay)- Los archivos rechazados incluyen un campo
errorcon el código de error para manejarlo de forma programática
Para las definiciones de estado de Import y la lógica de transición, consulta Procesamiento de Imports.
File API
Accede a la información de procesamiento de archivos y a las actualizaciones de estado.
Estructura de File
Notas:
- Cada archivo incluye un array
documentIds(siguiendo la convención de nombres: array de IDs en singular + sufijo “Ids”) - El campo
mimeTypeindica el formato del archivo (campo obligatorio) - Los archivos comprimidos (ZIP) tienen
compressed: truey un arraydocumentIdsvacío - Los archivos extraídos de un ZIP incluyen el campo
parentFileId, que referencia al archivo comprimido original - Los archivos rechazados (status: “rejected”) incluyen un campo
errorcon el código de error para manejarlo de forma programática - Todas las respuestas usan el campo
idcomo identificador principal (no_id) clientDatacontiene los metadatos personalizados aportados durante la subida (objeto vacío si no hay)
Para las definiciones de estado de File y la lógica de transición, consulta Procesamiento de Files.
Documents API
El procesamiento de documentos puede introducir latencia al recuperar información por ID de Document. Usa webhooks para actualizaciones en tiempo real.
Listar Documents: GET /v1/documents/
Obtener un Document: GET /v1/documents/{id}
Estructura de Document
La estructura completa del documento está disponible en la documentación de referencia de la API.
Para las definiciones de estado de Document y la lógica de transición, consulta Procesamiento de Documents.
Implementación técnica
Buenas prácticas
- Usa webhooks primero - el polling a la API debe complementar las notificaciones por webhook, no sustituirlas
- Implementa paginación - los conjuntos de resultados grandes se paginan por rendimiento
- Gestiona los límites de tasa - implementa backoff exponencial para las respuestas de rate limit
Manejo de errores
La API devuelve códigos de estado HTTP estándar:
- 200 - Éxito
- 400 - Petición incorrecta (errores de validación)
- 401 - No autorizado (revisa tu API key)
- 404 - Recurso no encontrado
- 429 - Límite de tasa superado
- 500 - Error interno del servidor
Las respuestas de error incluyen información detallada para ayudar con la depuración y la resolución.
Estrategias de polling
No recomendado en entornos de producción. Usa webhooks para actualizaciones en tiempo real en su lugar.
Cuando los webhooks no estén disponibles, usa estos patrones de polling:
- Carga inicial - haz polling cada 5-10 segundos durante el procesamiento activo
- Sincronización en segundo plano - haz polling cada 30-60 segundos para actualizaciones de estado
- Backoff exponencial - aumenta gradualmente los intervalos de polling (p. ej. 5s → 10s → 20s → 40s → 80s → 160s → 300s) hasta un máximo de 5 minutos, ya que el procesamiento de documentos puede ser complejo y llevar tiempo
- Peticiones por lotes - usa los endpoints de listado para reducir las llamadas a la API