- Introduction
- Quick start
- Philosophy
- Comparison
- Default behaviors
- Limitations
- Debugging runbook
- FAQ
- Mocking HTTP
- Mocking GraphQL
- Mocking WebSocket
- Integrations
- API
- CLI
- Best practices
- Recipes
Error responses
Simulating server error responses.
You can respond to the intercepted request with an error response by constructing a valid error Response
instance and returning it from the response resolver. This implies using an error status code (4xx
/5xx
) and optionally providing any custom response payload, such as an error message.
http.get<{ id: string }>('/books/:id', ({ params }) => {
if (params.id === 'abc-123') {
return new HttpResponse(null, { status: 404 })
}
return HttpResponse.json({
id: params.id,
title: 'The Lord of the Rings',
})
})
Type safety
Type safety of your error responses depends on how you define them. When using shorthands that infer the expected response body type, like HttpResponse.text()
and HttpResponse.json()
, error responses will remain type-safe:
http.get<never, never { id: string } | { error: message }>('/resource', ({ request }) => {
if (!request.headers.has('authorization')) {
return HttpResponse.json(
{ error: 'Unauthorized' },
{ status: 401 }
)
}
return HttpResponse.json({
id: 'abc-123',
})
})
Using the plain Response
instance ignores any response body types because its bodyInit
type cannot be narrowed—it’s always either null
, string
, or ReadableStream
. Use this to your advantage for error responses without a body.