API, CLI e MCP
Três formas de aceder à mesma conta, com os mesmos limites do plano e as mesmas permissões que o teu papel já te dá. Tudo o que está abaixo é uma destas três, por isso vale a pena saber qual delas procuraste.
API
REST, a partir de um pipeline, um script ou as tuas próprias ferramentas. Um token que crias e revogas tu mesmo, e JSON nos dois sentidos.
CLI
Um ficheiro Python, sem nada para instalar. A mesma API, para alguém num terminal em vez de um programa: listar o que está offline, adicionar um monitor.
MCP
Um endereço, colado no Claude ou noutro que fale o protocolo. Lê a conta e altera-a, como tu, numa conversa.
O teu token API
Cria um em API tokens na tua conta. É mostrado uma vez, guardamos apenas uma impressão digital dele, e pertence a ti em vez de à organização: não pode fazer mais do que tu podes, e deixa de funcionar se saíres ou o teu papel mudar. Escolhe leitura, ou leitura e escrita.
Envia-o como Authorization: Bearer n404_... em cada chamada. A primeira que vale a pena fazer é /api/v1/me, que responde por qual organização o token age, qual papel carrega e qual dos dois escopos tem: uma pessoa com duas contas tem dois tokens e nenhuma outra forma de saber qual está numa variável de ambiente.
O que está na versão 1
| Chamada | O que faz |
|---|---|
| GET /api/v1/me | O que este token é e por qual organização age |
| GET /api/v1/monitors | Todos os monitores, do mais antigo para o mais recente |
| POST /api/v1/monitors | Cria um, seguindo as mesmas regras que o formulário obedece |
| GET /api/v1/monitors/{id} | Um monitor |
| PATCH /api/v1/monitors/{id} | Altera o nome, endereço, intervalo ou configuração, ou pausa-o |
| DELETE /api/v1/monitors/{id} | Apaga-o, e o seu histórico com ele |
| GET /api/v1/monitors/{id}/status | O que está a fazer agora, e o seu uptime ao longo de uma janela |
| GET /api/v1/groups | Cada grupo, com quantos monitores estão nele |
| POST /api/v1/groups | Cria um; um nome que já existe devolve o grupo que o tem |
| GET /api/v1/groups/{id} | Um grupo |
| PATCH /api/v1/groups/{id} | Renomeia-o ou altera a sua descrição |
| DELETE /api/v1/groups/{id} | Apaga-o. Os seus monitores ficam, sem grupo |
| GET /api/v1/incidents | Falhas, mais recentes primeiro, filtradas por estado, monitor ou período |
| GET /api/v1/incidents/{id} | Um incidente, com os probes que o viram e confirmaram |
| GET /api/v1/maintenance | Janelas de manutenção e o que cobrem |
| GET /api/v1/maintenance/{id} | Uma janela, com os monitores e grupos que cobre |
| POST /api/v1/maintenance | Agenda uma, no horário da tua organização, para que um deploy possa abrir uma janela antes de começar |
| DELETE /api/v1/maintenance/{id} | Apaga-a. O que já cobria continua coberto |
| GET /api/v1/status-pages | Cada página de estado, e se está ativada |
| GET /api/v1/status-pages/{id} | Uma página, e o que está publicado nela |
| POST /api/v1/status-pages/{id}/monitors | Coloca um monitor na página, com o nome que o público deve ler |
| DELETE /api/v1/status-pages/{id}/monitors/{id} | Remove-o desta página. Outras páginas mantêm-no |
| POST /api/v1/status-pages/{id}/groups | Coloca um grupo na página; os monitores nele também vêm |
| DELETE /api/v1/status-pages/{id}/groups/{id} | Remove o cabeçalho. Os seus monitores continuam publicados |
Cada id num caminho ou corpo é o UUID, nunca um número. Escrever requer um token de leitura e escrita e uma função que possa escrever: o scope é o que entregaste a um programa, a função é o que te foi permitido entregar.
O documento é OpenAPI 3.1. Descreve cada chamada, o formato de cada corpo e o bearer token, para que um cliente possa ser gerado a partir dele em vez de escrito: openapi-generator, oapi-codegen e os restantes lêem-no como está. As operações têm nomes para uma pessoa, então os métodos gerados são listMonitors e createMonitor.
A versão 1 só cresce: um campo pode ser adicionado, nenhum é removido ou reescrito, e uma segunda versão seria um segundo caminho. Assim, um cliente gerado continua a funcionar, e regenerá-lo é como apanhas o que é novo.
Um cliente, se quiseres um
Um ficheiro, Python 3.9 ou mais recente, sem dependências. Faz o download, torna-o executável e coloca o teu token no ambiente. Faz tudo o que a API faz, porque cada comando é uma chamada às rotas acima.
curl -O https://nomore404.com/api/nomore404.py
curl -s https://nomore404.com/api/nomore404.py.sha256 | sha256sum -c
chmod +x nomore404.py
export N404_TOKEN=n404_...
./nomore404.py monitors list
./nomore404.py monitors add --type https --target shop.example.com
./nomore404.py incidents --state open
Vale a pena executar a segunda linha. Verifica o ficheiro contra o digest que publicamos ao lado, que é o digest exatamente do que este servidor envia, então um download que foi alterado no caminho não corresponde. ./nomore404.py --version indica de que versão veio, e cada pedido que faz diz o mesmo no seu User-Agent.
O token vem de N404_TOKEN ou de um ficheiro nomore404.env ao lado do script, nunca de uma flag na linha de comandos: um argumento é visível em ps para todos os utilizadores na máquina e fica no histórico do teu shell.
Para um assistente
Um assistente pode ler esta conta e alterá-la, através do Model Context Protocol. Há duas formas de acesso e não são a mesma coisa.
Um endereço, nada para instalar
Cola isto onde o teu assistente pedir um conector personalizado. Vai enviar-te aqui para fazer login e dizer para que organização é a ligação, e isso é toda a configuração.
Age como tu: a tua função é lida em cada chamada, então um assistente ligado por alguém que só pode ler só pode ler. Lê monitores, falhas, uptime, janelas de manutenção e grupos, e pode adicioná-los e alterá-los, o que inclui apagar um monitor e o histórico com ele. Desliga-o quando quiseres em Tokens da API, onde está listado ao lado deles.
Ou executa-o tu mesmo, e mantém-no a ler
nomore404_mcp.py serve a mesma API que as ferramentas da tua própria máquina. Mantém-no ao lado de nomore404.py, que usa para o token e para paginação. Lê e nunca escreve, que é a razão para escolhê-lo: um assistente é um chamador que pode ser convencido a fazer coisas, e uma ferramenta que apaga um monitor e o seu histórico está a um prompt de ser usada.
Dois ficheiros, um token ao lado deles, e uma linha para registar o servidor. Claude Code:
curl -O https://nomore404.com/api/nomore404.py
curl -O https://nomore404.com/api/nomore404_mcp.py
echo 'N404_TOKEN=n404_...' > nomore404.env
claude mcp add nomore404 -- python3 "$PWD/nomore404_mcp.py"
Qualquer outra coisa que fale o protocolo é o mesmo comando escrito como JSON, onde quer que esse cliente mantenha os seus servidores:
{
"mcpServers": {
"nomore404": {
"command": "python3",
"args": ["/path/to/nomore404_mcp.py"]
}
}
}
Nenhum nomeia o token, porque nenhum deve: é lido de nomore404.env ao lado dos scripts, ou de N404_TOKEN no ambiente com que o assistente o inicia. Depois pergunta-lhe o que está down, porque um incidente abriu, ou como um monitor esteve este mês.
Ambos têm algumas centenas de linhas e vale a pena lê-los antes de os executares. Nenhum está empacotado ou assinado, e nada te impede de gerar o teu próprio cliente a partir do documento.
Falhas e listas longas
Um formato de erro
O status indica a categoria. O corpo indica qual foi a falha, com um código para ramificar e uma frase para ler. A frase pode ser reformulada em qualquer versão, então nada deve analisá-la.
{
"error": {
"code": "monitor_not_found",
"message": "Nothing here with that id."
}
}
Cursors, não offsets
Uma listagem responde com items e next_cursor. Passa o cursor de volta para obter a próxima página e para quando for null. Incidentes chegam enquanto os estás a ler, e um offset mostraria silenciosamente uma linha duas vezes e nunca mostraria a próxima.
GET /api/v1/incidents?limit=50
GET /api/v1/incidents?limit=50&cursor=...
Quanto podes pedir
Um token pode fazer cento e vinte chamadas por minuto. Cada resposta inclui RateLimit-Remaining e RateLimit-Reset, para que um cliente bem-comportado possa gerir o ritmo em vez de descobrir o limite ao ultrapassá-lo. Acima do limite, há um 429 com Retry-After.