Skip to main content
The SDK provides type-safe error classes for handling different failure scenarios. All errors inherit from NotionClientError and include specific error codes.

Error Types

The SDK throws four distinct error types:

APIResponseError

Thrown when the Notion API returns an error response with a recognized error code.
Properties:
code
APIErrorCode
The error code returned by the API (e.g., unauthorized, object_not_found).
status
number
HTTP status code (e.g., 404, 429, 500).
message
string
Human-readable error message from the API.
headers
Headers
Response headers, including retry-after for rate limit errors.
body
string
Raw response body text.
request_id
string | undefined
Notion’s request ID for debugging. Include this when contacting support.
additional_data
Record<string, string | string[]> | undefined
Additional context from validation errors.

RequestTimeoutError

Thrown when a request exceeds the configured timeout (default 60 seconds).
Properties:
code
ClientErrorCode.RequestTimeout
Always "notionhq_client_request_timeout".

UnknownHTTPResponseError

Thrown when the API returns an error response that doesn’t match the expected error format.
Properties:
code
ClientErrorCode.ResponseError
Always "notionhq_client_response_error".
status
number
HTTP status code.
body
string
Raw response body text.

InvalidPathParameterError

Thrown when a path parameter contains path traversal sequences (e.g., ..) that could alter the request path.
Properties:
code
ClientErrorCode.InvalidPathParameter
Always "notionhq_client_invalid_path_parameter".

Error Codes

APIErrorCode

Error codes returned by the Notion API:

ClientErrorCode

Error codes generated by the SDK client:

Type Guards

Use type guards to narrow error types:

isNotionClientError

Check if an error is any SDK error:

isHTTPResponseError

Check if an error is an HTTP response error (has status, headers, body):

Specific Error Type Guards

Each error class has its own type guard:

Common Error Patterns

Handle Rate Limits

The SDK automatically retries rate limit errors (429) with exponential back-off. See Retries for details.

Handle Missing Resources

Handle Validation Errors

Retry on Server Errors

The SDK automatically retries server errors (500, 503) for idempotent methods (GET, DELETE). See Retries.

Log Request IDs

Always log request_id for debugging and support:

Error Handling Best Practices

  1. Always use type guards - Don’t assume error types
  2. Log request IDs - Essential for debugging with Notion support
  3. Handle specific codes - Match on error.code for different behaviors
  4. Let retries work - The SDK auto-retries transient errors
  5. Validate inputs - Check IDs and parameters before making requests