Add comprehensive request validation with Zod schemas

[wensiyuansix]

Summary

This PR implements comprehensive request validation using Zod schemas for authentication and employee management endpoints, improving input validation and type safety.

Problem

Several API endpoints had critical validation issues:

• Unsafe type assertions (as PostBody) without validation
• Missing input validation for employee operations
• No email format validation
• Potential for invalid data to reach business logic
• Type safety issues due to unvalidated inputs

Solution

Implement Zod validation schemas for all affected endpoints, leveraging the existing validateRequestBody utility.

Changes Made

New Validation Schemas

EmployeeIdSchema:

• Validates and coerces employee IDs to integers
• Ensures positive numbers only
• Clear error messages for invalid formats

SignupEmployeeSchema:

• Email format validation
• String length constraints (max 256 chars)
• Input trimming for whitespace
• Required field validation

SignupEmployerSchema:

• Similar validation to employee schema
• Specific to employer registration flow
• Separate passkey validation

Endpoint Updates

signup/employee/route.ts

• Added Zod validation before database operations
• Replaced unsafe type casting with validated data
• Enhanced error messages
• Email format validation

signup/employer/route.ts

• Implemented validation schema
• Fixed missing return statement bug
• Standardized error responses
• Input sanitization

approveEmployees/route.ts

• Added employee ID validation
• Automatic type coercion from string to number
• Prevents invalid ID manipulation

removeEmployees/route.ts

• Validation before delete operations
• Type-safe employee ID handling
• Better error messages

Security Benefits

1. Input Sanitization: Automatic trimming and length validation
2. Email Validation: Prevents malformed email addresses
3. Type Safety: Number coercion with validation
4. Early Rejection: Invalid inputs caught before database access
5. SQL Injection Prevention: Validated inputs reduce attack surface

Type Safety Improvements

• Eliminated unsafe type assertions (as PostBody)
• Type-safe validated data throughout handlers
• Compile-time guarantees through Zod inference
• No more unknown types passed to business logic

Error Message Quality

Before:

{ "error": {} }

After:

{
  "success": false,
  "error": "Validation Error",
  "message": "employeeId: Employee ID must be a positive number"
}

Testing

• ✅ TypeScript compilation passes
• ✅ No new type errors
• ✅ Zod schemas properly infer types
• ✅ Validation catches invalid inputs

Files Modified

• src/lib/validation.ts: Added 3 new schemas
• src/app/api/signup/employee/route.ts
• src/app/api/signup/employer/route.ts
• src/app/api/approveEmployees/route.ts
• src/app/api/removeEmployees/route.ts

Impact

Before:

• Unsafe type casting allowed invalid data
• No email validation
• Poor error messages
• Type safety issues

After:

• All inputs validated before processing
• Email format enforced
• Clear, actionable error messages
• Complete type safety

Breaking Changes

None - validation simply rejects previously invalid requests that would have caused errors downstream.

Related

This PR complements but is independent from the error handling standardization work, focusing specifically on input validation and type safety.

---

This improvement significantly enhances API reliability, security, and developer experience through proper input validation and type safety.

[vercel]

@jeanpunt is attempting to deploy a commit to the Timothy Lin's projects Team on Vercel.

A member of the Team first needs to authorize it.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
pdr-ai-v2	Ready	Preview	Comment	Nov 12, 2025 4:30pm