A aplicação reclama de JSON inválido, mas a API deveria devolver uma lista. Antes de investigar o parser, confira o status e o Content-Type. Um proxy pode estar devolvendo HTML de erro ou redirecionando a chamada para uma página de login.

curl --silent --show-error \
  --dump-header headers.txt \
  --output response.txt \
  --write-out 'HTTP %{http_code} em %{time_total}s\n' \
  https://api.example.com/items

Veja o arquivo de cabeçalhos e só depois abra o corpo. Um 200 com text/html e um 401 com application/json apontam para caminhos diferentes. Por padrão, o curl não segue redirecionamentos e pode terminar com sucesso mesmo diante de um status 4xx ou 5xx. Para automações que precisam falhar nesses casos e ainda guardar o corpo, use --fail-with-body se sua versão oferece a opção.

Se usar --verbose para reproduzir uma chamada autenticada, revise a saída antes de compartilhá-la. Cabeçalhos e cookies podem conter credenciais.

Documentação de referência · Como cancelar fetch e limitar o tempo de uma requisição

Interprete a resposta inteira

Um código 3xx indica um redirecionamento, mas o destino só fica claro ao conferir Location. Um 401 normalmente pede autenticação, enquanto 403 indica que a operação não foi autorizada; as APIs podem definir detalhes próprios. Um 204 não tem corpo. Validar Content-Type e status antes de chamar um parser reduz o risco de atribuir uma página de erro a um defeito do JSON.

Se precisa seguir redirects, use a opção correspondente e limite o número de saltos. Em uma API autenticada, confira se cabeçalhos sensíveis não são encaminhados a outro host. A opção para incluir cabeçalhos pode misturá-los com o corpo, então use dump-header e output quando o resultado precisa ser processado por outra ferramenta. Para teste de TLS, prefira corrigir a cadeia de certificados a desativar a validação.

Reduza a reprodução ao mínimo

Remova headers que não afetam o defeito e substitua tokens por credenciais fictícias antes de compartilhar o comando. Verbose pode exibir cabeçalhos de autorização, cookies e detalhes de proxy. Revise esses dados antes de anexar um log a uma Issue. Quando compara ambientes, mantenha o mesmo método, corpo e cabeçalhos e registre host e horário sem expor dados pessoais.

Teste primeiro um endpoint público e depois o autenticado. Compare o código e os cabeçalhos recebidos, não só a mensagem do terminal. Se a requisição usa proxy, veja se a resposta veio do serviço esperado e se o proxy acrescentou uma página de bloqueio ou redirecionamento.

Em shells diferentes, algumas opções e formas de escape precisam de atenção. Mantenha o corpo de um POST em arquivo quando ele contém aspas, acentos ou quebra de linha. Assim, o comando fica mais legível e você reduz erros de interpretação do shell. Ao guardar a saída para comparação, anote o método e a URL consultados, retire credenciais do arquivo e não envie o arquivo para o Git se houver dados de usuário. Uma reprodução mínima é mais útil do que um log completo com segredo.