Skip to content

API do servidor

Esta página descreve a superfície REST e WebSocket exposta por jarvis server.

Página canônica em inglês

Esta referência é mantida em inglês e acompanha o código de perto: caminhos, campos, códigos de erro e tipos de evento mudam a cada release. Para evitar que uma tradução defasada informe um contrato errado, a versão canônica é a única mantida:

Server API (inglês)

As demais páginas da documentação existem integralmente em português. Esta é a única exceção, junto do changelog.

Por onde começar

Se você quer conduzir uma sessão pela API, comece pelo guia em português, que cobre o fluxo completo com exemplos:

  • Servidor local e API — iniciar o servidor, autenticar, criar uma sessão, assinar eventos e enviar prompts
  • Comando jarvis — todas as opções de linha de comando do jarvis server

Contrato em resumo

Estes pontos do contrato são estáveis o bastante para serem resumidos aqui; para qualquer detalhe além disso, use a página canônica.

  • Endereço padrão: http://127.0.0.1:58627, apenas loopback. Uma porta ocupada é tentada de novo com porta + 1.
  • Superfícies: REST em /api/v1, eventos em /api/v1/ws.
  • Autenticação: bearer token obrigatório em todo endpoint /api/*. Em REST, use o cabeçalho Authorization: Bearer <token>; em WebSocket, clientes que não definem cabeçalhos usam o subprotocolo jarvis-code.bearer.<token>.
  • Envelope de resposta: toda resposta JSON tem a forma { "code": 0, "msg": "success", "data": ..., "request_id": "..." }. O resultado de negócio está em code, onde 0 significa sucesso; o status HTTP reporta apenas o resultado de transporte.
  • Especificações ao vivo: GET /openapi.json descreve a API REST e GET /asyncapi.json descreve o protocolo WebSocket. Ambos exigem o bearer token e refletem exatamente a versão que você está executando — prefira-os a qualquer documentação estática.
  • Superfície de depuração: as rotas /api/v1/debug/* só são montadas com --debug-endpoints, em bind loopback e sob a mesma autenticação bearer global.

WARNING

As APIs REST e WebSocket são experimentais. A estabilidade da interface não é garantida, e endpoints, campos e tipos de evento podem mudar em qualquer release.

Próximos passos