Sinalização digital headless: um script, um pipeline ou um agente opera as telas

Em um sistema de sinalização tradicional, o app web é a superfície de controle e o player o segue. Em um sistema headless, o controle fica em uma API. Qualquer cliente chama o mesmo plano de controle, o plano de controle decide o que cada Player reproduz, e o Player renderiza e informa de volta. O dashboard é só mais um cliente, e nenhum cliente precisa ficar aberto para que uma tela continue reproduzindo.

Programável significa que o código controla o que é reproduzido. Programático costuma significar a compra automatizada de espaços publicitários em telas out-of-home, o que Players trata à parte.

A equipe de plataforma quer o pipeline de releases na TV ao lado da máquina de café: cada etapa assim que acontece, da mais recente para a mais antiga, com uma linha vermelha quando algo falha. O pipeline, os números de job e os hosts são conteúdo de demonstração. A execução é real: 26 de outubro de 2026, no ambiente de staging do screenRIG, com as imagens desenhadas pelo Player em uma janela do navegador no lugar da TV. Cada etapa do pipeline executa um pequeno script uma vez:

1. Pipeline iniciado. main, 3 commits.
2. Testes aprovados. 412 testes em 3 min 10 s.
3. Falha no deploy para produção. A verificação de integridade expirou em web-2, revertendo.
4. Rollback concluído. web-1 e web-2 saudáveis novamente.

Depois da terceira etapa, o erro é a linha grande, as etapas anteriores aparecem com suas idades, e o rodapé conta os eventos e erros da hora. Depois da quarta, o rollback fica no topo e o deploy com falha fica abaixo dele.

A parte do agente é curta e acontece uma única vez. Ele cria um painel Feed de atividade, dá a ele uma primeira linha para que a página não fique vazia e o coloca na tela. Depois entrega ao pipeline um script. O script lê o painel e sua revisão, coloca a nova linha em primeiro lugar e grava de volta apenas se ninguém tiver gravado nesse intervalo:

# $url is the board's address and $auth carries your token.
# 1. Read the board and its revision (the ETag).
etag=$(curl -sS -D - -o current.json -H "$auth" "$url" | awk 'tolower($1) == "etag:" { print $2 }' | tr -d '\r')
# 2. Write the board back with the new row first. A stale revision is refused, and the script reads again.
curl -sS -X PUT "$url" -H "$auth" -H "Content-Type: application/json" -H "If-Match: $etag" -H "Idempotency-Key: board-$(date -u +%s%N)" --data @next.json

Ele não faz polling. O stream de eventos do projeto pode ser reproduzido, e um pipeline pode lê-lo enquanto grava. No caso do deploy com falha, o stream trouxe a gravação, a alteração e, em seguida, o relatório do próprio Player informando que aplicou aquela revisão àquela página (horários em UTC, reduzidos a evento e revisão):

03:43:47.501  kv.updated                 revision 5 written
03:43:47.505  screen.card_data_changed   revision 5
03:43:49.306  screen.card_data_applied   revision 5, page "board"

O Player informou a revisão 1,8 segundo depois de a gravação ser aceita. Um job que não deve continuar até que a tela mostre uma falha pode esperar por essa última linha, e um job que não se importa pode ignorá-la. Os eventos de tela são gratuitos no stream de escuta, e uma reconexão retoma a partir do último cursor.

Dois jobs podem gravar ao mesmo tempo. Uma gravação com uma revisão desatualizada é recusada, e a recusa informa qual é a revisão atual, então ninguém sobrescreve uma linha mais nova. O script lê de novo e tenta outra vez, até três vezes.

Tudo o que precisa continuar funcionando quando nenhum cliente está conectado. O Player renderiza; o servidor decide.

Uma tag seleciona uma frota, então um único comando alcança todas as telas que a têm.

O dashboard é só mais um cliente, e algumas tarefas combinam mais com uma pessoa.

• Revisões. Um agente conectado com o acesso Propor, ou um projeto que exige revisão, envia as alterações para a página Revisões. Uma pessoa aprova, pede mudanças ou rejeita, e nada chega a uma tela antes disso.
• Acesso. A página Acesso lista todos os agentes, apps conectados e clientes de serviço, e uma pessoa pode encerrar qualquer um deles ali.
• Pessoas e projetos. Convites e configurações de projeto ficam com as pessoas.

Sinalização digital headless é o mesmo que sinalização digital API-first?

Descrevem o mesmo projeto por dois lados. API-first significa que a API é projetada primeiro e todo cliente a usa. Headless significa que nenhuma interface específica é necessária para operar as telas.

Preciso de um desenvolvedor para operar sinalização digital headless?

Não. Um agente pode operar tudo a partir de uma frase, e uma pessoa aprova o que ele propõe quando o projeto exige revisão. Um desenvolvedor acrescenta scripts como o de cima quando um sistema deve gravar em uma tela por conta própria.

Posso manter meu conteúdo em outro sistema?

Sim. Um script lê o sistema e grava os valores em um painel. As telas renderizam o que o servidor guarda.

Quais Players uma configuração headless controla?

Doze: o Player web, Android e Google TV, o Amazon Signage Stick, Apple TV, macOS, iPhone e iPad, Windows, Linux, Raspberry Pi, LG webOS Signage, Samsung Smart Signage (Tizen) e BrightSign. O guia de Players traz os passos de instalação.

A sinalização digital headless é grátis?

O screenRIG é grátis, com telas ilimitadas. Os planos pagos acrescentam ferramentas de negócios, mais pessoas, pessoas com quem conversar, governança e condições contratuais. Veja os preços; Desenvolvedores mostra cada interface.

Leia a referência da API REST para ver as chamadas que o script faz, ou comece grátis e deixe seu agente escrever o script.