POST/api/public/contact

Zentor 웹사이트의 공개 연락처 양식. 내부 리드 시스템에 문의를 생성합니다.

`POST /api/public/contact`는 Zentor 웹사이트의 공개 연락처 양식을 처리하며, 요청을 내부 리드 시스템에 저장합니다. 이 엔드포인트는 대시보드 인증이 필요하지 않으며, 멱등성(idempotent)을 보장하지 않습니다. 각 성공적인 제출은 새로운 리드를 생성할 수 있으므로, 프론트엔드는 첫 번째 클릭 후 전송 버튼을 비활성화하고 자동 재시도를 트리거하지 않아야 합니다. 확실한 필수 필드에는 `name`, `email`, `message`가 포함됩니다. 이름은 2자에서 120자 사이여야 하며, 이메일 주소는 유효한 형식을 가져야 하고, 메시지는 서버 측 유효성 검사 규칙을 충족해야 합니다. 추가 필드는 실제 스키마에 명시된 경우에만 전송해야 합니다. 알 수 없는 값은 리드의 내부 속성을 제어하는 데 사용되어서는 안 됩니다. 올바른 양식은 브라우저에서 필수 필드를 이미 검사하지만, 이러한 검사에만 의존해서는 안 됩니다. 서버 측 검사가 핵심입니다. 유효성 검사 오류가 발생하면 인터페이스는 해당 필드를 표시하고 입력된 내용을 유지해야 합니다. 일반적인 성공 메시지는 서버의 긍정적인 응답 이후에만 표시되어야 합니다. 연락처 양식은 비밀번호, API 키, 위젯 토큰, 결제 데이터 또는 전체 고객 데이터 레코드를 전송하기 위한 안전한 채널이 아닙니다. 사용자는 사용 사례, 관련 제품 및 연락 가능한 비즈니스 이메일 주소를 제공해야 합니다. 기술적 문제의 경우, 불필요한 개인 정보를 전달하지 않으면서도_tenant_ 이름, 발생 시간, 관련 기능 및 재현 가능한 단계를 제공하면 도움이 됩니다. 현실적인 흐름은 다음과 같습니다. 방문자가 이름, 이메일 및 메시지를 작성하고, 필요시 사이트의 개인정보 보호 안내를 확인한 후 양식을 제출합니다. 서버는 데이터를 유효성 검사하고 리드를 생성한 후 성공 응답을 반환합니다. 유효하지 않은 이메일이나 너무 짧은 이름의 경우 완전한 리드가 생성되지 않습니다. 이 엔드포인트는 _tenant_를 생성하지 않으며, 패키지를 예약하지도 않고, 구조화된 제품 구성이나 상담 프로세스를 대체하지도 않습니다. 스팸 및 자동화된 일괄 요청으로부터 보호하기 위해 클라이언트는 서버 측 오류를 존중하고 즉시 무한 루프를 시작해서는 안 됩니다. 성공적인 응답은 서버가 수락을 확인한 후에만 입력 필드를 비워야 합니다. 응답이 없는 경우, 사용자는 내용을 저장하고 나중에 통제된 방식으로 다시 제출할 수 있습니다. 내부 할당을 위해 메시지는 마케팅 구호나 기밀 첨부 파일 없이 실제 원인을 포함해야 합니다. 명확한 제목과 정확한 문제 설명은 추가 문의를 줄여줍니다. 그러나 API 자체는 보장된 우선순위를 할당하지 않으며, 고정된 처리 기간을 확인하지도 않습니다.

{"name":"Max Mustermann","email":"max@example.com","message":"귀하의 메시지 (최소 10자).","consentGiven":true}

{"ok":true,"message":"요청이 전송되었습니다."}