Claims and adjustment

flowchart LR
    E[Evento] --> D[Detección]
    D --> C[POST /v1/claims]
    C --> P[POST /v1/peritajes]
    P --> R[POST /v1/reports]
    R --> V[POST /v1/verify]

An adjustment (peritaje) hangs off a claim and a detection. The rule is enforced by the contract: an adjustment without a measurement is not evidence, it is an opinion with formatting.

curl -sS "$SBOX/v1/claims" -X POST \
  -H "authorization: Bearer $TOKEN" \
  -H "idempotency-key: claim-demo-0001" \
  -H "content-type: application/json" \
  -d '{
    "aoiId": "<aoiId>",
    "peril": "hail",
    "status": "submitted",
    "eventWindow": { "start": "2026-01-14T20:00:00.000Z", "end": "2026-01-14T23:00:00.000Z" },
    "claimedLossUsd": 42000,
    "syntheticReporterRef": "synthetic_adjuster_demo"
  }'

curl -sS "$SBOX/v1/peritajes" -H "authorization: Bearer $TOKEN"

What breaks

422 invalid_request_body with the offending field flagged when the claim points to an AOI that does not exist in the organization. Referential integrity is validated as a whole, not per resource: a broken link passes any individual validation and only breaks in the demo, where there is no stacktrace.

Permissions are claims permissions (claims:read / claims:write), not portfolio ones. Someone who can see the portfolio does not see the claims.

Endpoints in this guide

• GET/POST /v1/claims
• GET /v1/claims/{id}
• GET/POST /v1/peritajes