Skip to main content
Las listas paginan de a máximo 100 filas por solicitud, lo cual es correcto para una app y equivocado para una carga de BI. Las exportaciones producen un archivo con el conjunto de datos completo y filtrado de una entidad (procesos, actuaciones o demandados), hasta 100.000 filas, y te entregan una URL de descarga.
Como un portafolio grande tarda más de lo que una sola solicitud debería esperar, una exportación corre como trabajo asíncrono: la misma solicitud puede resolverse de tres maneras, y tú eliges cuál le conviene a tu app.
Las exportaciones pequeñas se sienten síncronas. Por defecto la solicitud espera hasta 20 segundos y, si el archivo está listo, devuelve 200 { data } con la URL. Los otros modos son opcionales, para cuando prefieras no mantener la conexión abierta.

La solicitud

Los campos desconocidos en el cuerpo (o dentro de filters) se rechazan con 400. El resultado, una vez existe el archivo:
  • url es imposible de adivinar pero no está autenticada: cualquiera que la tenga puede descargar el archivo. Está garantizada hasta expires_at (24 horas después de completarse) y se elimina poco después; descárgala pronto y no la publiques en ningún lugar público.
  • truncated: true significa que se alcanzó el tope de 100.000 filas y el archivo no es el conjunto completo. Acota los filtros (por ejemplo por rango de fechas) y exporta de nuevo.

Las tres formas de obtener el resultado

Los tres están respaldados por el mismo trabajo, así que elige por solicitud.

Modo 1: Esperar en línea (por defecto)

Solo llama al endpoint. La solicitud se mantiene abierta hasta que el archivo está listo (hasta 20 segundos por defecto) y devuelve { data }.
Controla cuánto esperar con el encabezado estándar Prefer: wait=N (segundos, con tope en 55):
  • 200: listo. El cuerpo es { "data": … } como arriba.
  • 202: no terminó dentro de la espera. El cuerpo es un sobre de trabajo; sigue su status_url para hacer polling. El encabezado X-Job-Id trae el id del trabajo.
Maneja siempre tanto 200 como 202. Un 202 no es un error; solo significa “todavía generando, vuelve por el resultado”. Un portafolio con decenas de miles de actuaciones normalmente tarda más que los 20 segundos de espera por defecto.

Modo 2: Polling

Envía Prefer: wait=0 para recibir un 202 de inmediato y luego haz GET al status_url del trabajo hasta que llegue a un estado terminal.
GET /jobs/:id siempre devuelve 200 con el sobre. Mientras el trabajo sigue corriendo incluye un encabezado Retry-After (segundos); úsalo para marcar el ritmo del polling. El polling tiene su propia cuota generosa. Los trabajos están limitados a tu organización; un trabajo de otra organización se lee como 404.

Modo 3: Callback (webhook)

Incluye un callback_url en el cuerpo de la solicitud. Recibes un 202 de inmediato y Croma hace POST con el resultado a tu URL cuando el archivo está listo, sin polling.
callback_url debe ser una URL HTTPS absoluta en un host público (localhost y los rangos privados se rechazan). Cuando el trabajo termina, Croma envía un POST:
  • Cuerpo: el mismo sobre de trabajo del endpoint de polling.
  • x-croma-job-id: el id del trabajo.
  • x-croma-signature: sha256=<hmac>, un HMAC-SHA256 del cuerpo crudo de la solicitud, para que verifiques la integridad de la carga.
La verificación de la firma usa un secreto compartido emitido por Croma; contáctanos si quieres habilitarla para tus callbacks. Responde 2xx rápido; las respuestas distintas de 2xx se reintentan.

El sobre del trabajo

La respuesta 202, GET /jobs/:id y el cuerpo del callback comparten una misma forma:
  • data solo viene poblado cuando status es completed. Si no, es null.
  • error solo viene poblado cuando el trabajo está en failed, como { "type", "code", "message" } con code: "job_failed".

Estados

Qué trae el archivo

Las columnas son las mismas elijas csv o jsonl. Los valores anidados (metadata) se serializan como texto JSON en las celdas del CSV.
id, registration_number, plaintiff_name, defendant_name, defendant_id, office, status, registration_date, last_discovery_date, is_private, latest_action_message, latest_action_date, metadata.Las dos columnas latest_action_* traen la actuación más reciente de cada proceso, así que el archivo se lee como la vista de portafolio del dashboard.

Referencia de encabezados

POST /v1/exports

Esquema completo de solicitud y respuesta, con los filtros por entidad.

Errores

Cómo funcionan las fallas y el objeto error.