POST/api/public/contact
Formulário público de contacto do website Zentor. Cria um pedido no sistema interno de leads.
`POST /api/public/contact` processa o formulário público de contacto do website Zentor e guarda o pedido no sistema interno de leads. O endpoint não exige autenticação de dashboard e não é idempotente. Cada submissão bem-sucedida pode criar um novo lead. Por isso, após o primeiro clique o frontend deve desativar o botão Enviar e não executar retries automáticos. Os campos obrigatórios confirmados incluem `name`, `email` e `message`. O nome tem de ter entre 2 e 120 caracteres, o endereço de e-mail um formato válido e a mensagem tem de cumprir as regras de validação do servidor. Outros campos só devem ser enviados se fizerem parte do schema real. Valores desconhecidos não devem ser usados para controlar propriedades internas do lead. Um formulário correto verifica os campos obrigatórios já no browser, mas não depende apenas dessa validação. O servidor continua a ser autoritativo. Em erro de validação, a interface deve assinalar o campo afetado e preservar os dados introduzidos. Uma mensagem genérica de sucesso só deve aparecer após resposta positiva do servidor. O formulário de contacto não é um canal seguro para palavras-passe, API Keys, Widget Tokens, dados de pagamento ou conjuntos completos de dados de clientes. Os utilizadores devem indicar o caso de utilização, o produto afetado e um e-mail empresarial acessível. Em problemas técnicos, ajudam nome do tenant, momento, função afetada e passos reproduzíveis, sem transmitir dados pessoais desnecessários. Fluxo realista: o visitante preenche nome, e-mail e mensagem, confirma se necessário a informação de privacidade da página e envia o formulário. O servidor valida os dados, cria o lead e devolve sucesso. Com e-mail inválido ou nome demasiado curto, não é criado um lead completo. O endpoint não cria tenant, não contrata pacote e não substitui a configuração estruturada de produto nem o processo de aconselhamento. Para proteção contra spam e pedidos automatizados em série, o cliente deve respeitar erros do servidor e evitar loops imediatos. Uma resposta bem-sucedida só deve limpar os campos depois de o servidor confirmar a aceitação. Se não houver resposta, o utilizador pode guardar o conteúdo e voltar a enviar mais tarde de forma controlada. Para associação interna, a mensagem deve conter o motivo real, sem frases de marketing nem anexos confidenciais. Um assunto claro e uma descrição precisa reduzem perguntas adicionais. A API, contudo, não atribui prioridade garantida nem confirma prazo fixo de processamento.
Autenticação e segurança
Não é necessária autenticação
Idempotente: Não
Parâmetros
name(body, string, obrigatório)— 2–120 caracteresemail(body, string, obrigatório)— Endereço de e-mail válidomessage(body, string, obrigatório)— 10–3000 caracterescompany(body, string)phone(body, string)topic(body, string)consentGiven(body, boolean, obrigatório)— Tem de ser true (consentimento de privacidade)Pedido de exemplo
{"name":"Max Mustermann","email":"max@example.com","message":"A sua mensagem (mín. 10 caracteres).","consentGiven":true}Resposta de exemplo
{"ok":true,"message":"Ihre Anfrage wurde übermittelt."}Códigos de erro
400 VALIDATION_ERROR — Campo obrigatório em falta/inválido ou consentimento de privacidade em falta (array de details com mensagens individuais).Evidência de teste live
Sucesso (200) e caso negativo (400, campos em falta incluindo consentimento) verificados live.