Qualquer código de erro HTTP seria inadequado. Não há nenhum erro ou problema de qualquer tipo a partir de uma perspectiva HTTP, então deve ser algo no intervalo de 200. Você educadamente informa alguns de seus usuários que eles não serão atendidos enviando de volta um documento que os informa. E tudo isso vai bem.
O usuário não poderá usar seu aplicativo . Essa é uma decisão consciente feita por sua lógica de negócios, não um contratempo. No nível do HTTP, tudo é honky.
Editar
Parece que o que estamos vendo aqui é um choque entre a velha escola e a nova escola. Quando o HTTP foi projetado, não havia serviços da Web, não havia SOAP, sem JSON, sem princípios REST. Como um protocolo acima do TCP, isso já era considerado (próximo a) nível de aplicação e muitos códigos de status de alto nível foram definidos. Quando a web começou a ser usada para serviços mais sofisticados e de alto nível, era necessário um meio comum para transportar "envelopes", projetando HTTP de alta tecnologia em vez de definir um protocolo mais novo e mais limpo, só porque o HTTP era onipresente.
Assim, em um contexto de serviço da Web moderno, o HTTP é, na verdade, pouco mais que uma camada de transporte burra e a maioria de seus códigos pode ser considerada não aplicável ou obsoleta. Basta escolher um, porque ele se aproxima do estado do seu aplicativo e, por acaso, está na lista que uma vez significou que algo pode parecer inofensivo, mas acho que ele enviaria uma mensagem errada. Você não quer que o HTTP desempenhe essa função reguladora em um contexto de serviço da Web.