Peritaje de daños
Cuánto se dañó el lote tras un evento de granizo, inundación o sequía — con el paso previo que evita gastar cuota en un cálculo que todavía no se puede hacer.
Responde: ¿cuánta superficie del lote se dañó tras este evento? Es el producto más caro de los tres y el único con tres pasos, porque tiene un problema que los otros no: después de un evento puede que todavía no haya imagen satelital utilizable.
Tres pasos, y por qué
Fuente del diagrama (mermaid)
sequenceDiagram
participant C as Tu sistema
participant A as API
C->>A: POST /v1/damage/feasibility
A-->>C: 200 · { status: ready | pending_post_imagery | cloud_blocked }
Note over C: si no está ready, no gastes: reintentá más tarde
C->>A: POST /v1/damage/assessments
A-->>C: 202 · trabajo encolado
C->>A: POST /v1/damage/reports { assessmentId }
A-->>C: 202 · trabajo encolado
El primer paso no consume cuota y por eso no exige Idempotency-Key: sólo
consulta el catálogo de escenas. Consultarlo antes de peritar te evita pagar por
un cálculo que va a devolver "no se puede todavía".
1. ¿Se puede peritar ya?
curl -s -X POST "$BASE/v1/damage/feasibility" \
-H "Authorization: Bearer $UCOTRON_API_KEY" \
-H "content-type: application/json" \
-d '{
"ring": [[-59.95,-35.05],[-59.94,-35.05],[-59.94,-35.06],[-59.95,-35.06],[-59.95,-35.05]],
"peril": "granizo",
"eventDate": "2026-02-15"
}'El peril va en español: granizo, inundacion o sequia. Otro valor
responde unsupported_peril.
status | Qué significa | Qué hacer |
|---|---|---|
ready | Hay escenas previas y posteriores utilizables | Peritar |
pending_post_imagery | Todavía no hubo pasada del satélite después del evento | Reintentar tras nextExpectedPass (la revisita es de ~5 días) |
cloud_blocked | Hay imagen posterior pero está tapada por nubes | Reintentar tras retryAfter |
unsupported_peril | Ese peligro no se peritä por satélite | No insistir |
invalid_event | Fecha futura, o ventana invertida | Corregir el pedido |
La sequía casi siempre da ready: se computa contra una climatología de varios
años y no necesita una escena posterior puntual.
2. Computar el daño
De dónde sale aoi_ref
Es la referencia a un lote ya dibujado, no una geometría que viaje en el pedido. Es el único punto en que el peritaje se aparta de los otros dos productos, que reciben las coordenadas en la misma llamada.
demo:lote-1 es un lote de ~123 ha que existe en los dos entornos. Sirve para
recorrer el flujo entero antes de tener uno propio, y es el que usan los
ejemplos de esta página.
Todavía no hay endpoint para dar de alta un lote en esta superficie. Si
mandás una referencia que no existe, el trabajo termina en failed con
aoi_not_found: no es un error del pedido, es que ese lote no está. Mientras
tanto, para peritar lotes propios, escribinos.
curl -s -X POST "$BASE/v1/damage/assessments" \
-H "Authorization: Bearer $UCOTRON_API_KEY" \
-H "content-type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d '{
"parameters": {
"aoi_ref": "demo:lote-1",
"aoiVersion": 1,
"event_ref": "ev-granizo-2026-02-15",
"peril": "granizo",
"eventDate": "2026-02-15",
"threshold": 0.18,
"licenceTier": "unverified"
}
}'Devuelve 202. El resultado trae las hectáreas dañadas, el porcentaje afectado
y la procedencia: qué ventanas se compararon, cuántas escenas de cada lado y con
qué corte de nubes.
aoiVersion entra en la identidad del cálculo: redibujar el lote es otro
peritaje, y tiene que serlo — un peritaje sobre una geometría vieja afirmaría
algo sobre una superficie que ya no es la del lote.
3. Emitir el dossier
curl -s -X POST "$BASE/v1/damage/reports" \
-H "Authorization: Bearer $UCOTRON_API_KEY" \
-H "content-type: application/json" \
-H "Idempotency-Key: $(uuidgen)" \
-d '{"assessmentId":"job_footprint_…","locale":"es-AR"}'El assessmentId es el id del trabajo del paso 2, ya en succeeded. El
dossier cita ese peritaje: de ahí salen las ventanas comparadas y las escenas
usadas, que es lo que el documento declara.
Lo que se rompe
| Qué pasa | Respuesta | Por qué |
|---|---|---|
peril en inglés, o uno no soportado | unsupported_peril | Va en español: granizo, inundacion, sequia |
eventDate en el futuro | invalid_event | No se perita algo que no pasó |
| Peritar sin consultar viabilidad, con el post todavía nublado | el trabajo falla | Por eso el paso 1 existe y es gratis |
Falta Idempotency-Key en los pasos 2 o 3 | 428 | Los dos gastan cuota. El paso 1 no la pide |
assessmentId de un trabajo que no terminó | el trabajo falla | El dossier cita un peritaje cerrado, no uno en curso |
| El lote no existe en tu organización | 404 | Contesta igual que una ruta inexistente, a propósito |
La tabla completa de códigos está en Trabajos, entrega y errores.
Qué afirma, y qué no
- Compara escenas previas y posteriores al evento sobre el mismo lote. Lo que detecta es un cambio en la respuesta espectral, compatible con daño.
- La nubosidad degrada el resultado. El informe declara el corte usado y cuántas escenas quedaron de cada lado.
- La inundación se detecta hoy con índices ópticos: bajo nubes persistentes la sensibilidad cae. El radar (que ve a través de nubes) es una mejora pendiente y está declarada como limitación en el documento.
- La resolución es de 10 m: daños en parches menores a eso no se resuelven individualmente.
Es evidencia técnica reproducible sobre superficie afectada. No reemplaza una inspección en campo ni fija un monto indemnizatorio.