Alert: riferimento API, endpoint ed esempi

OpenAPI YAML OpenAPI JSON problemi YAML Panoramica dell’API

Questo gruppo ha 6 operazioni, generate da api/openapi.yaml. Filtra per percorso, azione o autenticazione. Ogni endpoint elenca i suoi input; espandilo per vedere un modello di richiesta e i codici di risposta. I modelli richiedono i tuoi valori e un corpo valido secondo lo schema.

Sostituisci i segnaposto maiuscoli con i tuoi valori. Per una richiesta JSON, salva un corpo che corrisponde allo schema in request.json. Gli esempi di cookie usano un cookie jar locale da una sessione autenticata.

Alert: problemi aperti degli schermi, riconoscimento, posticipo e silenziamenti

GET/api/alerts¶

Elenca alert

Elenca gli alert degli schermi del progetto: uno per schermo e condizione finché dura (open) e quelli terminati entro il periodo di conservazione degli eventi del piano (resolved).

Un alert si apre quando arriva l’evento della sua condizione (screen.offline, un cambiamento di salute display_disconnected, temperature_high o on_battery, screen.storage_shortfall, uno screen.manifest_upgrade bloccato, uno screen.status_changed di livello error, uno screen.glass_changed con verdetto bloccato, vuoto o congelato) e si risolve con l’evento di ripristino; crashing è un avviso, non un alert. counts.attention conta gli alert aperti che non sono riconosciuti, posticipati o silenziati, il numero mostrato dal dashboard.

Uno schermo che si riavvia per un riavvio inviato dal backend non apre alert screen_offline o display_disconnected finché il riavvio non è completato o fino a dieci minuti dopo l'invio; una condizione che persiste allora apre il suo alert in quel momento. Gli alert aperti vengono per primi, dal più recente; passa next_cursor come prima per la pagina successiva.

Autenticazione: projectBearer O dashboardSession
Corpo della richiesta: nessuno
ID operazione: listAlerts

Parametri

Nome	Invia	Obbligatorio?	Descrizione
ScreenRig-Project	intestazione	opzionale	Deprecato per una release. Deve essere coerente con le concessioni JWT dei progetti; aggiunge intestazioni Deprecation e Warning. Nessuno scambio di token.
formato	query	opzionale	json (predefinito) restituisce il report come JSON. csv, xlsx e pdf restituiscono le stesse righe come allegato (ogni pagina di un report a pagine, fino a 50000 righe).
stato	query	opzionale
screen_id	query	opzionale
before	query	opzionale	next_cursor della pagina precedente.
limite	query	opzionale

Modello richiesta e risposte

shell · modello richiesta

curl --request GET --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/alerts'

Risposte

Stato	Significato	Corpo e intestazioni
200	Una pagina di alert.	AlertList (application/json)
predefinito	Risposta problema stabile RFC 9457. Un 421 server_draining ha Retry-After di 1 secondo, un 500 not_ready o dependency_unavailable ha 5, e un 500 manifest_degraded ha 60, salvo valore più specifico impostato dal gestore.	Problema (application/problem+json)

GET/api/alerts/{id}¶

Ottieni alert

Un alert.

Autenticazione: projectBearer O dashboardSession
Corpo della richiesta: nessuno
ID operazione: getAlert

Parametri

Nome	Invia	Obbligatorio?	Descrizione
ScreenRig-Project	intestazione	opzionale	Deprecato per una release. Deve essere coerente con le concessioni JWT dei progetti; aggiunge intestazioni Deprecation e Warning. Nessuno scambio di token.
id	path	obbligatorio

Modello richiesta e risposte

shell · modello richiesta

curl --request GET --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/alerts/RESOURCE_ID'

Risposte

Stato	Significato	Corpo e intestazioni
200	L’alert.	Alert (application/json)
predefinito	Risposta problema stabile RFC 9457. Un 421 server_draining ha Retry-After di 1 secondo, un 500 not_ready o dependency_unavailable ha 5, e un 500 manifest_degraded ha 60, salvo valore più specifico impostato dal gestore.	Problema (application/problem+json)

POST/api/alerts/{id}/acknowledge¶

Riconosci alert

Riconosce un alert aperto: qualcuno se ne sta occupando. Senza until resta riconosciuto finché non si risolve; con until (non oltre 30 giorni più avanti) viene posticipato e richiede di nuovo attenzione in quell’istante se è ancora aperto. Finché è riconosciuto o posticipato, l’avviso di una notifica che lo riguarda e che è ancora nel tempo di attesa viene saltato (acknowledged).

Un riconoscimento successivo sostituisce il precedente. Aggiunge screen.alert_acknowledged. Un alert risolto è alert_not_open.

Autenticazione: projectBearer O dashboardSession
Corpo della richiesta: AlertAcknowledge
ID operazione: acknowledgeAlert

Parametri

Nome	Invia	Obbligatorio?	Descrizione
ScreenRig-Project	intestazione	opzionale	Deprecato per una release. Deve essere coerente con le concessioni JWT dei progetti; aggiunge intestazioni Deprecation e Warning. Nessuno scambio di token.
id	path	obbligatorio
Idempotency-Key	intestazione	opzionale	Ometti per un’operazione fresca. Fornisci e riutilizza una chiave per deduplicare i retry; la CLI gestisce automaticamente le chiavi.

Campi del corpo della richiesta

Campo	Descrizione
until (opzionale, string)	Posticipa fino a questo istante, al massimo 30 giorni più avanti. Se assente: riconosciuto fino alla risoluzione dell’alert. format: "date-time"

Modello richiesta e risposte

shell · modello richiesta

curl --request POST --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt --header 'Content-Type: application/json' --data '@request.json' 'https://screenrig.ai/api/alerts/RESOURCE_ID/acknowledge'

Risposte

Stato	Significato	Corpo e intestazioni
200	L’alert riconosciuto.	Alert (application/json)
409	alert_not_open.	Problema (application/problem+json)
predefinito	Risposta problema stabile RFC 9457. Un 421 server_draining ha Retry-After di 1 secondo, un 500 not_ready o dependency_unavailable ha 5, e un 500 manifest_degraded ha 60, salvo valore più specifico impostato dal gestore.	Problema (application/problem+json)

GET/api/alert-mutes¶

Elenca silenziamenti alert

Elenca i silenziamenti del progetto non ancora terminati, a partire da quello che termina prima (al massimo 50).

Autenticazione: projectBearer O dashboardSession
Corpo della richiesta: nessuno
ID operazione: listAlertMutes

Parametri

Nome	Invia	Obbligatorio?	Descrizione
ScreenRig-Project	intestazione	opzionale	Deprecato per una release. Deve essere coerente con le concessioni JWT dei progetti; aggiunge intestazioni Deprecation e Warning. Nessuno scambio di token.

Modello richiesta e risposte

shell · modello richiesta

curl --request GET --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/alert-mutes'

Risposte

Stato	Significato	Corpo e intestazioni
200	I silenziamenti attivi del progetto.	AlertMuteList (application/json)
predefinito	Risposta problema stabile RFC 9457. Un 421 server_draining ha Retry-After di 1 secondo, un 500 not_ready o dependency_unavailable ha 5, e un 500 manifest_degraded ha 60, salvo valore più specifico impostato dal gestore.	Problema (application/problem+json)

POST/api/alert-mutes¶

Crea silenziamento alert

Silenzia gli schermi per manutenzione fino a un istante non oltre 30 giorni più avanti: gli schermi indicati da screen_ids e ogni schermo con uno qualsiasi dei tag in tags al momento in cui un avviso deve essere inviato. I loro alert continuano ad aprirsi e a risolversi, contrassegnati con muted, e non richiedono mai attenzione; gli avvisi di ogni notifica che li riguardano vengono saltati (muted).

Un’organizzazione ha al massimo 50 silenziamenti attivi in tutti i suoi progetti (alert_mute_limit_reached). Aggiunge alert_mute.created.

Autenticazione: projectBearer O dashboardSession
Corpo della richiesta: AlertMuteWrite
ID operazione: createAlertMute

Parametri

Nome	Invia	Obbligatorio?	Descrizione
ScreenRig-Project	intestazione	opzionale	Deprecato per una release. Deve essere coerente con le concessioni JWT dei progetti; aggiunge intestazioni Deprecation e Warning. Nessuno scambio di token.
Idempotency-Key	intestazione	opzionale	Ometti per un’operazione fresca. Fornisci e riutilizza una chiave per deduplicare i retry; la CLI gestisce automaticamente le chiavi.

Campi del corpo della richiesta

Campo	Descrizione
screen_ids (opzionale, array)
tag (opzionale, ScreenTags)	Tag selettore flotta, da 0 a 16 tag unici esatti, ciascuno conforme alla grammatica dei tag media. Su ScreenPatch l’array sostituisce l’intero set e un array vuoto lo cancella; un tag duplicato o malformato è invalid_request. Cambiare i tag aggiorna la revisione dello schermo (protetta da If-Match) e aggiunge screen.updated con details.tags; non modifica mai la revisione del manifesto. I tag non sono mai nel manifesto di runtime e mai nell’autorizzazione.
until (obbligatorio, string)	Al massimo 30 giorni più avanti. format: "date-time"
note (facoltativo, string)	maxLength: 200

Modello richiesta e risposte

shell · modello richiesta

curl --request POST --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt --header 'Content-Type: application/json' --data '@request.json' 'https://screenrig.ai/api/alert-mutes'

Risposte

Stato	Significato	Corpo e intestazioni
201	Creato.	AlertMute (application/json)
409	alert_mute_limit_reached o idempotency_mismatch.	Problema (application/problem+json)
predefinito	Risposta problema stabile RFC 9457. Un 421 server_draining ha Retry-After di 1 secondo, un 500 not_ready o dependency_unavailable ha 5, e un 500 manifest_degraded ha 60, salvo valore più specifico impostato dal gestore.	Problema (application/problem+json)

ELIMINA/api/alert-mutes/{id}¶

Elimina silenziamento alert

Termina subito un silenziamento e aggiunge alert_mute.deleted.

Autenticazione: projectBearer O dashboardSession
Corpo della richiesta: nessuno
ID operazione: deleteAlertMute

Parametri

Nome	Invia	Obbligatorio?	Descrizione
ScreenRig-Project	intestazione	opzionale	Deprecato per una release. Deve essere coerente con le concessioni JWT dei progetti; aggiunge intestazioni Deprecation e Warning. Nessuno scambio di token.
id	path	obbligatorio
Idempotency-Key	intestazione	opzionale	Ometti per un’operazione fresca. Fornisci e riutilizza una chiave per deduplicare i retry; la CLI gestisce automaticamente le chiavi.

Modello richiesta e risposte

shell · modello richiesta

curl --request DELETE --header 'Authorization: Bearer [SCREENRIG_TOKEN]' --cookie cookies.txt --cookie-jar cookies.txt 'https://screenrig.ai/api/alert-mutes/RESOURCE_ID'

Risposte

Stato	Significato	Corpo e intestazioni
204	Terminato.	nessun corpo
predefinito	Risposta problema stabile RFC 9457. Un 421 server_draining ha Retry-After di 1 secondo, un 500 not_ready o dependency_unavailable ha 5, e un 500 manifest_degraded ha 60, salvo valore più specifico impostato dal gestore.	Problema (application/problem+json)