dry_run, quindi invia. Il server valida
esattamente come un salvataggio nella web app, poi calcola il punteggio e persiste una nuova
valutazione.
Tutte le richieste si autenticano con un header X-Aegister-Token (vedi
Autenticazione e API token).
L’organizzazione deve possedere la licenza v_ciso. La lettura richiede il ruolo view;
la scrittura richiede il ruolo edit (security_officer, owner o super_admin).
I percorsi qui sotto sono abbreviati come
.../workflows/{wid}/.... La base completa è
https://app.aegister.com/api/v1/v-ciso/organizations/{oid}. Tutte le risposte usano
l’envelope standard { "error": 0|1, "messages": [], "data": {…} } (più "total" negli elenchi).Prima di iniziare
Questa guida parte da un’organizzazione esistente che possiede già la licenzav_ciso e ha
il framework che vuoi compilare associato e configurato. Ti servono solo il suo id
organizzazione ({oid}) e un token con il ruolo edit (security_officer, owner o super_admin).
1. Individua cosa compilare
Elenca ogni attività (tabella e a domande) dell’organizzazione, ciascuna con il suotype,
così che uno script possa localizzare su cosa lavorare. Filtra con ?type=table o ?type=questions.
workflow_id + task_id restituiti per le chiamate per-attività. Il più datato
GET .../table-tasks (Elenca attività tabella) restituisce solo le attività tabella; /tasks le copre entrambe.
2. Attività tabella (righe)
Leggi la specifica (il contratto)
type, required, un format dichiarativo (per esempio
{ "kind": "date", "pattern": "YYYY-MM-DD" }) e i valori ammessi in choices (con sia
l’id value sia il label localizzato). Le colonne dipendenti riportano depends_on +
choices_by_parent; le colonne cross-attività riportano source. Invia il label della scelta
oppure il suo value id; le colonne a valori multipli accettano un array o una stringa unita da |.
Valida senza scrivere (dry_run)
errors (un id di colonna che non è nella specifica, scelta errata,
data/numero non validi, un valore figlio non ammesso per il suo genitore, un valore cross-attività
sconosciuto) e ripeti finché error_count è 0.
Messaggi ed etichette delle colonne seguono ?lan=en|it (inglese per impostazione predefinita);
un valore obbligatorio mancante porta "code": "required", così uno script lo riconosce senza
leggere il testo. current ti permette di confrontare ciò che invii con ciò che la tabella
contiene prima di inviare. Riporta le celle come le mostra la console (testo localizzato, scelte
come etichette), quindi non rimandarlo come rows: costruisci le righe a partire dalla specifica.
Il body JSON deve contenere un array rows: senza, la richiesta fallisce con 400 e
Missing 'rows' array. dry_run vale solo se è true, 1 o yes (nel body o come parametro
di query); qualsiasi altro valore significa invio.
Sostituisci la tabella, o mantieni le righe che non invii
Per impostazione predefinita le righe che invii sostituiscono l’intera tabella. Aggiungi"keep_rows": true (oppure ?keep_rows=1, o un campo keep_rows nel form con un caricamento
XLSX) per aggiornarla invece: una riga la cui prima colonna corrisponde a una riga già presente
la sostituisce, le righe nuove vanno in fondo e le righe che non hai inviato restano. Si legge
come dry_run (true, 1 o yes).
kept_count, il numero di righe attuali che restano.
Invia
Rimuovidry_run per persistere. Il server valida di nuovo, invia al motore di calcolo del
punteggio e registra una nuova valutazione, esattamente come un salvataggio nella web app.
keep_rows, la risposta contiene anche kept_rows.
Una richiesta con un qualsiasi errore di validazione restituisce 400 con error: 1 e la lista
data.errors; non viene scritto nulla.
3. Attività a domande (risposte)
Le attività a domande usano gli stessi endpoint/spec e /import; la chiave del payload è
answers invece di rows. Leggi la specifica e le risposte correnti in un’unica chiamata per il
prefill, quindi invia.
Unknown id: not a question of this task or step (see /spec)).
{ "value", "evidence": [<path>], "note": [{ "id", "response" }] }. Carica prima il file
(vedi sezione 5) e usa il path restituito: deve
essere un file caricato per la stessa organizzazione, lo stesso workflow e la stessa domanda,
altrimenti la risposta viene rifiutata. Ogni id di nota deve essere una delle notes della
domanda in /spec; per una domanda di un’attività è <question_id>_justification:
dry_run per persistere; la risposta riporta il nuovo evaluation_id, come per le tabelle.
4. Controlli del framework
Il framework di un workflow (l’insieme di controlli dietro il punteggio) ha il proprio trio spec/answers/submit, raggruppato in step. Lavora uno step alla volta con?step=<stepId>.
id, label, description, type
(radio|select|checkbox|date|number|text|…), choices, required, un flag evidence
(se è possibile allegare file), notes (i campi di giustificazione, ciascuno con il suo id),
step, subframework, category e weight. Un id di controllo che non è nello step è un errore.
Invia le risposte di uno step con controls-import: prima dry_run, poi persisti.
id della nota è quello indicato nelle notes del controllo (per i controlli NIS 2,
ad esempio 2.1.1_justification):
value insieme alla nota. Su ISO 27001 una risposta che contiene solo la
giustificazione, senza valore, cancella il livello del controllo.
Rimuovendo dry_run valida e poi invia tramite /evaluate (Aegister calcola il punteggio e persiste),
restituendo { "submitted": <numero di risposte>, "step": "E", "evaluation_id": … }.
5. Evidenze: il caricamento in due passi
Carica le evidenze separatamente, non inline. Invia il file al suo artefatto, quindi riferisci ilpath restituito nella risposta.
Passo 1, carica il file come JSON base64 verso l’artefatto (un id di controllo o di domanda):
413); i formati ammessi sono PDF, Word
(.doc/.docx), Excel (.xls/.xlsx), immagini e video (qualsiasi altro restituisce 400). I caricamenti
vengono deduplicati per SHA-256 (un contenuto identico restituisce la versione esistente, 200, invece di
una nuova 201), e per ogni artefatto vengono conservate solo le ultime 10 versioni.
Passo 2, riferisci il path restituito nell’array evidence della risposta che invii
(sezioni 3 e 4).
Per elencare le evidenze esistenti in un workflow (ogni artefatto con la sua ultima versione e
l’intera cronologia), chiama GET .../workflows/{wid}/documents (Elenca documenti nella barra laterale).
La cronologia e i download per-artefatto usano gli altri endpoint del gruppo
Virtual CISO → Cyber Posture → Documenti.
6. Compila un’attività dai tuoi documenti (AI)
Se le risposte sono già nei tuoi documenti (una policy, un elenco di asset, un registro), lascia che l’AI li legga e proponga cosa inserire in un’attività tabella o a domande. È la stessa proposta di Compila dai tuoi documenti nella console. Non viene salvato nulla: rivedi la proposta e la invii tramite/import come nelle sezioni 2 e 3.
Passo 1, avvia il job con da 1 a 5 documenti in base64 (al massimo 10 MB ciascuno, 20 MB in
totale, altrimenti 413). Puoi avviare 20 job all’ora; oltre, la chiamata risponde 429:
skipped con il
motivo. La chiamata fallisce con 400 quando nessun documento è leggibile e con 502 quando il
servizio AI non è raggiungibile.
Passo 2, interroga il job finché status è done:
{ "status": "running" }. Quando i documenti non contengono nulla per
l’attività, il risultato porta un msg invece di una proposta. Per un’attività a domande, kind
è questions e la proposta è in answers, indicizzata per id della domanda. ai spiega la
proposta: un riepilogo, quanti elementi sono stati compilati, per ogni risposta la confidenza e il
documento da cui viene, e le righe escluse con il motivo (per esempio un valore che manca in un
elenco collegato, da aggiungere prima lì).
Passo 3, invia la proposta: manda rows (tabelle) o answers (domande) a /import, prima
con dry_run. Solo chi ha avviato il job può leggerlo, e i documenti non vengono conservati.
