A DTO (Data Transfer Object) is a class that defines the shape of data sent to or from your API — typically the structure of a request body. DTOs provide type safety, serve as a clear contract for endpoints, and (with validation decorators) enable automatic input validation.
{ , , , , , } ;
{
()
: ;
()
()
: ;
()
()
()
?: ;
}
A DTO is a plain class describing the expected data, with validation decorators (from class-validator) specifying the rules each field must satisfy.
@Post()
create(@Body() dto: CreateUserDto) { // the body is typed AND validated as CreateUserDto
// dto is guaranteed to be valid here (with the validation pipe enabled)
return this.usersService.create(dto);
}
The @Body() dto: CreateUserDto types the request body and — with the validation pipe enabled — automatically validates it before your handler runs.
// main.ts — turn on the global validation pipe
app.useGlobalPipes(new ValidationPipe({
whitelist: true, // strip properties NOT in the DTO (security)
forbidNonWhitelisted: true, // reject requests with extra unknown properties
transform: true, // auto-transform payloads to DTO instances + convert types
}));
With the ValidationPipe, NestJS validates incoming bodies against the DTO's decorators automatically — returning a 400 error with details if validation fails, before your code runs.
DTO → the shape of data crossing the API boundary (request/response contract)
Entity → the database model (e.g. a TypeORM entity / Prisma model)
→ Keep them SEPARATE: the API contract shouldn't be coupled to the DB schema.
(A CreateUserDto has password+email; the User entity has id, timestamps, etc.)
DTOs deliberately differ from database entities — they represent what the API accepts/returns, decoupled from internal storage.
import { PartialType } from "@nestjs/mapped-types";
// derive an UpdateUserDto where all fields are optional — no duplication
export class UpdateUserDto extends PartialType(CreateUserDto) {}
DTOs are an important NestJS pattern that brings type safety, clear API contracts, and automatic validation to your endpoints.
They define exactly what data an endpoint accepts (the request shape), giving you compile-time typing and serving as self-documenting contracts.
Crucially, combined with class-validator decorators and the ValidationPipe, they enable automatic input validation — malformed or malicious requests are rejected with clear errors before reaching your business logic, which is essential for security and robustness (the whitelist option also strips unexpected properties).
Understanding DTOs, how to add validation rules, how to enable the validation pipe, and the important principle of keeping DTOs separate from database entities (decoupling the API contract from internal storage) is fundamental for building safe, well-structured, maintainable NestJS APIs.
DTOs appear in virtually every endpoint that accepts input, making them everyday, essential knowledge.