POST/api/public/contact

Formulario público de contacto del sitio de Zentor. Crea una solicitud en el sistema interno de leads.

`POST /api/public/contact` procesa el formulario público de contacto del sitio de Zentor y crea la solicitud en el sistema interno de leads. El endpoint no necesita autenticación de dashboard y no es idempotente. Cada envío correcto puede crear un nuevo lead. Por eso el frontend debe deshabilitar el botón de envío tras el primer clic y no iniciar reintentos automáticos. Entre los campos obligatorios confirmados están `name`, `email` y `message`. El nombre debe tener entre 2 y 120 caracteres, el correo debe tener formato válido y el mensaje debe cumplir las reglas de validación del servidor. Otros campos solo deben enviarse si están previstos en el esquema real. No deben utilizarse valores desconocidos para intentar controlar propiedades internas del lead. Un formulario correcto valida los campos obligatorios ya en el navegador, pero no depende únicamente de esa comprobación. El servidor sigue siendo autoritativo. Ante un error de validación, la interfaz debe marcar el campo afectado y conservar los contenidos introducidos. Solo debe mostrar un mensaje genérico de éxito tras una respuesta positiva del servidor. El formulario de contacto no es un canal seguro para contraseñas, API Keys, Widget Tokens, datos de pago o conjuntos completos de datos de clientes. Los usuarios deberían indicar el caso de uso, el producto afectado y una dirección de correo empresarial accesible. Para un problema técnico ayudan el nombre del tenant, la hora, la función afectada y pasos reproducibles, sin transferir datos personales innecesarios. Flujo realista: el visitante rellena nombre, correo y mensaje, confirma si procede el aviso de privacidad de la página y envía el formulario. El servidor valida los datos, crea el lead y devuelve una respuesta correcta. Con un correo inválido o un nombre demasiado corto no se crea un lead completo. El endpoint no crea un tenant, no contrata un paquete y no sustituye la configuración estructurada de producto ni el proceso de asesoramiento. Para proteger frente a spam y solicitudes automatizadas en serie, el cliente debe respetar los errores del servidor y no iniciar bucles inmediatos infinitos. Una respuesta correcta solo debería vaciar los campos cuando el servidor confirme la recepción. Si no llega respuesta, el usuario puede conservar el contenido y enviarlo de nuevo posteriormente de forma controlada. Para la asignación interna, el mensaje debe contener el motivo real sin frases publicitarias ni adjuntos confidenciales. Un asunto claro y una descripción precisa reducen preguntas posteriores. La API no asigna una prioridad garantizada ni confirma un plazo fijo de tramitación.

{"name":"Max Mustermann","email":"max@example.com","message":"Su mensaje (mín. 10 caracteres).","consentGiven":true}

{"ok":true,"message":"Ihre Anfrage wurde übermittelt."}