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:
urles imposible de adivinar pero no está autenticada: cualquiera que la tenga puede descargar el archivo. Está garantizada hastaexpires_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: truesignifica 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 }.
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 sustatus_urlpara hacer polling. El encabezadoX-Job-Idtrae 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íaPrefer: 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 uncallback_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 respuesta202, GET /jobs/:id y el cuerpo del callback comparten una
misma forma:
datasolo viene poblado cuandostatusescompleted. Si no, esnull.errorsolo viene poblado cuando el trabajo está enfailed, como{ "type", "code", "message" }concode: "job_failed".
Estados
Qué trae el archivo
Las columnas son las mismas elijascsv o jsonl. Los valores anidados
(metadata) se serializan como texto JSON en las celdas del CSV.
- processes
- actions
- defendants
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.