Shield: flujos y ejemplos
Ejemplos prácticos para la rama v1 (canal con API key). Para IA e integrations, el patrón es el mismo nivel lógico: obtener JWT válido para esa rama y enviarlo en Authorization.
Secuencia Shield v1 (canal con API key)
Fuente: diagrams/shield-v1-authorize.mmd — yarn diagrams:build. Clic en el diagrama para ampliarlo.
Paso 1: obtener token
La ruta GET /api/shield/v1/auth/authorize espera la cabecera x-api-key (no Authorization). Respuesta exitosa: cuerpo con el token emitido (formato ShieldResponse.ok).
curl -sS -X GET "https://TU_DOMINIO/api/shield/v1/auth/authorize" \
-H "x-api-key: TU_CHANNEL_API_KEY"
Paso 2: listar risk items (ejemplo)
curl -sS -G "https://TU_DOMINIO/api/shield/v1/risk-items" \
-H "Authorization: Bearer TU_ACCESS_TOKEN_JWT" \
--data-urlencode "from=0" \
--data-urlencode "to=50"
Con filtro por póliza:
curl -sS -G "https://TU_DOMINIO/api/shield/v1/risk-items" \
-H "Authorization: Bearer TU_ACCESS_TOKEN_JWT" \
--data-urlencode "policyId=UUID_POLIZA"
Crear risk item (POST)
curl -sS -X POST "https://TU_DOMINIO/api/shield/v1/risk-items" \
-H "Authorization: Bearer TU_ACCESS_TOKEN_JWT" \
-H "Content-Type: application/json" \
-d '{"package_uid":"...","policy_uid":"...", ... }'
Los campos exactos dependen de v.riskItem.shield.insert() en el código.
Códigos HTTP habituales
| Código | Significado |
|---|---|
200 | Éxito |
201 | Recurso creado |
400 | Validación / cabeceras incorrectas |
401 | Token inválido o expirado |
403 | Sin permisos |
404 | Recurso no encontrado |
422 | Datos no procesables (unprocessableContent) |