Alertas: referência da API, endpoints e exemplos

OpenAPI YAML OpenAPI JSON problemas YAML Visão geral da API

Este grupo tem 6 operações, geradas a partir de api/openapi.yaml. Filtre por caminho, ação ou autenticação. Cada endpoint lista suas entradas; expanda-o para ver um modelo de solicitação e os códigos de resposta. Os modelos precisam de seus próprios valores e de um corpo válido conforme o esquema.

Substitua os espaços reservados em maiúsculas pelos seus valores. Para uma solicitação JSON, salve um corpo que corresponda ao esquema em request.json. Exemplos de cookies usam um jar local de cookies de uma sessão autenticada.

Alertas: problemas de tela abertos, reconhecimento, adiamento e silenciamentos

GET/api/alerts¶

Listar alertas

Lista os alertas de tela do projeto: um por tela e condição enquanto ela durar (open), e os que terminaram dentro da retenção de eventos do plano (resolved).

Um alerta é aberto quando chega o evento de sua condição (screen.offline, uma mudança de saúde display_disconnected, temperature_high ou on_battery, screen.storage_shortfall, um screen.manifest_upgrade travado, um screen.status_changed de nível error, um screen.glass_changed com veredito travado, em branco ou congelado) e é resolvido pelo evento que a encerra; crashing é um aviso, não um alerta. counts.attention conta os alertas abertos que não estão reconhecidos, adiados nem silenciados, o número que o dashboard mostra.

Uma tela que reinicia por causa de um reinício enviado pelo backend não abre alerta screen_offline nem display_disconnected até que o reinício termine ou dez minutos depois de enviado; uma condição que ainda se mantém então abre seu alerta nesse momento. Os alertas abertos vêm primeiro, os mais recentes antes; passe next_cursor de volta como antes para a próxima página.

Autenticação: projectBearer OU dashboardSession
Corpo da solicitação: nenhum
ID da operação: listAlerts

Parâmetros

Nome	Enviar	Obrigatório?	Descrição
ScreenRig-Project	cabeçalho	opcional	Obsoleto por uma versão. Deve ser consistente com as concessões de projetos JWT; adiciona cabeçalhos Deprecation e Warning. Sem troca de token.
formato	consulta	opcional	json (padrão) retorna o relatório como JSON. csv, xlsx e pdf retornam as mesmas linhas como anexo (cada página de um relatório paginado, até 50000 linhas).
estado	consulta	opcional
screen_id	consulta	opcional
before	consulta	opcional	next_cursor da página anterior.
limite	consulta	opcional

Modelo e respostas da solicitação

shell · modelo de requisição

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

Respostas

Status	Significado	Corpo e cabeçalhos
200	Uma página de alertas.	AlertList (application/json)
padrão	Resposta de problema estável RFC 9457. Um 421 server_draining tem Retry-After de 1 segundo, um 500 not_ready ou dependency_unavailable tem 5, e um 500 manifest_degraded tem 60, a menos que o handler defina valor mais específico.	Problema (application/problem+json)

GET/api/alerts/{id}¶

Obter alerta

Um alerta.

Autenticação: projectBearer OU dashboardSession
Corpo da solicitação: nenhum
ID da operação: getAlert

Parâmetros

Nome	Enviar	Obrigatório?	Descrição
ScreenRig-Project	cabeçalho	opcional	Obsoleto por uma versão. Deve ser consistente com as concessões de projetos JWT; adiciona cabeçalhos Deprecation e Warning. Sem troca de token.
id	caminho	obrigatório

Modelo e respostas da solicitação

shell · modelo de requisição

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

Respostas

Status	Significado	Corpo e cabeçalhos
200	O alerta.	Alert (application/json)
padrão	Resposta de problema estável RFC 9457. Um 421 server_draining tem Retry-After de 1 segundo, um 500 not_ready ou dependency_unavailable tem 5, e um 500 manifest_degraded tem 60, a menos que o handler defina valor mais específico.	Problema (application/problem+json)

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

Reconhecer alerta

Reconhece um alerta aberto: alguém está cuidando dele. Sem until, ele permanece reconhecido até ser resolvido; com until (no máximo 30 dias à frente), ele é adiado e volta a precisar de atenção nesse instante se ainda estiver aberto. Enquanto está reconhecido ou adiado, o aviso de uma notificação sobre ele que ainda está em tempo de espera é ignorado (acknowledged).

Um reconhecimento posterior substitui o anterior. Registra screen.alert_acknowledged. Um alerta resolvido retorna alert_not_open.

Autenticação: projectBearer OU dashboardSession
Corpo da solicitação: AlertAcknowledge
ID da operação: acknowledgeAlert

Parâmetros

Nome	Enviar	Obrigatório?	Descrição
ScreenRig-Project	cabeçalho	opcional	Obsoleto por uma versão. Deve ser consistente com as concessões de projetos JWT; adiciona cabeçalhos Deprecation e Warning. Sem troca de token.
id	caminho	obrigatório
Idempotency-Key	cabeçalho	opcional	Omitir para uma operação nova. Forneça e reutilize uma chave para deduplicar tentativas; o CLI gerencia as chaves automaticamente.

Campos do corpo da solicitação

Campo	Descrição
until (opcional, string)	Adie até este instante, no máximo 30 dias à frente. Ausente: reconhecido até o alerta ser resolvido. format: "date-time"

Modelo e respostas da solicitação

shell · modelo de requisição

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'

Respostas

Status	Significado	Corpo e cabeçalhos
200	O alerta reconhecido.	Alert (application/json)
409	alert_not_open.	Problema (application/problem+json)
padrão	Resposta de problema estável RFC 9457. Um 421 server_draining tem Retry-After de 1 segundo, um 500 not_ready ou dependency_unavailable tem 5, e um 500 manifest_degraded tem 60, a menos que o handler defina valor mais específico.	Problema (application/problem+json)

GET/api/alert-mutes¶

Listar silenciamentos de alerta

Lista os silenciamentos do projeto que não terminaram, começando pelo que termina primeiro (no máximo 50).

Autenticação: projectBearer OU dashboardSession
Corpo da solicitação: nenhum
ID da operação: listAlertMutes

Parâmetros

Nome	Enviar	Obrigatório?	Descrição
ScreenRig-Project	cabeçalho	opcional	Obsoleto por uma versão. Deve ser consistente com as concessões de projetos JWT; adiciona cabeçalhos Deprecation e Warning. Sem troca de token.

Modelo e respostas da solicitação

shell · modelo de requisição

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

Respostas

Status	Significado	Corpo e cabeçalhos
200	Os silenciamentos vigentes do projeto.	AlertMuteList (application/json)
padrão	Resposta de problema estável RFC 9457. Um 421 server_draining tem Retry-After de 1 segundo, um 500 not_ready ou dependency_unavailable tem 5, e um 500 manifest_degraded tem 60, a menos que o handler defina valor mais específico.	Problema (application/problem+json)

POST/api/alert-mutes¶

Criar silenciamento de alerta

Silencia telas para manutenção até um instante no máximo 30 dias à frente: as telas nomeadas em screen_ids e toda tela que tenha alguma das tags listadas em tags no momento em que um aviso deve ser enviado. Os alertas delas continuam sendo abertos e resolvidos, marcados como muted, e nunca precisam de atenção; os avisos de todas as notificações sobre elas são ignorados (muted).

Uma organização tem no máximo 50 silenciamentos vigentes em todos os seus projetos (alert_mute_limit_reached). Registra alert_mute.created.

Autenticação: projectBearer OU dashboardSession
Corpo da solicitação: AlertMuteWrite
ID da operação: createAlertMute

Parâmetros

Nome	Enviar	Obrigatório?	Descrição
ScreenRig-Project	cabeçalho	opcional	Obsoleto por uma versão. Deve ser consistente com as concessões de projetos JWT; adiciona cabeçalhos Deprecation e Warning. Sem troca de token.
Idempotency-Key	cabeçalho	opcional	Omitir para uma operação nova. Forneça e reutilize uma chave para deduplicar tentativas; o CLI gerencia as chaves automaticamente.

Campos do corpo da solicitação

Campo	Descrição
screen_ids (opcional, array)
tags (opcional, ScreenTags)	Tags do seletor de frota, de 0 a 16 tags únicas exatas, cada uma correspondendo à gramática de tags de mídia. No ScreenPatch o array substitui o conjunto inteiro e um array vazio o limpa; uma tag duplicada ou malformada é invalid_request. Alterar tags aumenta a revisão da tela (If-Match a protege) e anexa screen.updated com details.tags; nunca altera a revisão do manifesto. Tags nunca estão no manifesto de tempo de execução e nunca na autorização.
until (obrigatório, string)	No máximo 30 dias à frente. format: "date-time"
note (opcional, string)	maxLength: 200

Modelo e respostas da solicitação

shell · modelo de requisição

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'

Respostas

Status	Significado	Corpo e cabeçalhos
201	Criada.	AlertMute (application/json)
409	alert_mute_limit_reached ou idempotency_mismatch.	Problema (application/problem+json)
padrão	Resposta de problema estável RFC 9457. Um 421 server_draining tem Retry-After de 1 segundo, um 500 not_ready ou dependency_unavailable tem 5, e um 500 manifest_degraded tem 60, a menos que o handler defina valor mais específico.	Problema (application/problem+json)

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

Excluir silenciamento de alerta

Encerra um silenciamento agora e registra alert_mute.deleted.

Autenticação: projectBearer OU dashboardSession
Corpo da solicitação: nenhum
ID da operação: deleteAlertMute

Parâmetros

Nome	Enviar	Obrigatório?	Descrição
ScreenRig-Project	cabeçalho	opcional	Obsoleto por uma versão. Deve ser consistente com as concessões de projetos JWT; adiciona cabeçalhos Deprecation e Warning. Sem troca de token.
id	caminho	obrigatório
Idempotency-Key	cabeçalho	opcional	Omitir para uma operação nova. Forneça e reutilize uma chave para deduplicar tentativas; o CLI gerencia as chaves automaticamente.

Modelo e respostas da solicitação

shell · modelo de requisição

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

Respostas

Status	Significado	Corpo e cabeçalhos
204	Encerrado.	sem corpo
padrão	Resposta de problema estável RFC 9457. Um 421 server_draining tem Retry-After de 1 segundo, um 500 not_ready ou dependency_unavailable tem 5, e um 500 manifest_degraded tem 60, a menos que o handler defina valor mais específico.	Problema (application/problem+json)