This file provides guidance to Claude Code (claude.ai/code) when working with code in this repository.
Official Notion SDK for JavaScript - a TypeScript client library providing type-safe access to the Notion API.
- Package:
@notionhq/client - Target Runtime: Node.js ≥ 18
- TypeScript: ≥ 5.9
- Build System: TypeScript compiler (tsc)
- Test Framework: Jest with ts-jest
npm run build # Runs: npm run clean && tsc
npm run clean # Remove build/ directorynpm test # Run all tests in test/To run a single test file:
npx jest test/helpers.test.tsnpm run lint # Runs prettier, eslint, and cspell
npm run prettier # Format code with prettiernpm run install:examples # Install dependencies for all example projects
npm run examples:typecheck # Type-check all examplesThe SDK is organized around a central Client class (src/Client.ts) that exposes namespaced endpoints:
client.blocks- Block CRUD operations and children managementclient.databases- Database CRUD operationsclient.dataSources- Data source operations and queryingclient.pages- Page CRUD operations and property retrievalclient.users- User listing and retrievalclient.comments- Comment CRUD operationsclient.fileUploads- File upload lifecycle (create, send, complete, list)client.oauth- OAuth token, introspect, and revoke operationsclient.search()- Search across workspace
Each endpoint namespace contains methods like retrieve, create, update, delete, and list as appropriate. Child resources use nested objects (e.g., client.blocks.children.list()).
All API calls flow through Client.request() which:
- Constructs the full URL from
baseUrl+path - Validates path against traversal attacks
- Adds authentication headers (from client-level
author request-level override) - Sets
Notion-Versionheader (defaults to "2025-09-03") - Handles request timeout (default 60s)
- Automatically retries on transient errors (rate limits, server errors)
- Processes response or throws typed errors
The client automatically retries failed requests for these error codes:
rate_limited(HTTP 429) - retried for all HTTP methods; respectsretry-afterheader if presentinternal_server_error(HTTP 500) - retried only for idempotent methods (GET, DELETE)service_unavailable(HTTP 503) - retried only for idempotent methods (GET, DELETE)
Server errors (500, 503) are only retried for idempotent methods to avoid duplicate side effects. Rate limits (429) are retried for all methods since the server explicitly asks clients to retry.
Configuration via ClientOptions.retry:
const client = new Client({
auth: "secret_...",
retry: {
maxRetries: 2, // Default: 2 retry attempts
initialRetryDelayMs: 1000, // Default: 1 second base delay
maxRetryDelayMs: 60000, // Default: 60 second cap
},
})
// Or disable retries entirely:
const client = new Client({ auth: "secret_...", retry: false })When retry-after header is present, the client waits for that duration (capped by maxRetryDelayMs). Otherwise, it uses exponential back-off with jitter.
Generated Types (src/api-endpoints.ts):
- DO NOT EDIT - This file is auto-generated from the Notion API specification
- Contains all request/response types and endpoint definitions
- Each endpoint exports:
Parameters,Responsetypes, and a descriptor withpath,method,queryParams,bodyParams
Type Guards (src/type-utils.ts and src/helpers.ts):
isFullPage(),isFullBlock(),isFullDataSource(),isFullUser(),isFullComment()isFullPageOrDataSource()- handles union typesisNotionClientError()- for error handling
ID Extraction (src/helpers.ts):
extractNotionId(),extractPageId(),extractDatabaseId(),extractBlockId()- Extract IDs from Notion URLs or format raw IDs
Four error types (all in src/errors.ts):
APIResponseError- HTTP errors from Notion API with error codes fromAPIErrorCodeRequestTimeoutError- Request exceeded timeoutUnknownHTTPResponseError- Unexpected HTTP responsesInvalidPathParameterError- Path contains traversal sequences
Error codes are in two enums:
APIErrorCode- Server-side errors (unauthorized, rate_limited, object_not_found, etc.)ClientErrorCode- Client-side errors (request_timeout, response_error, invalid_path_parameter)
Type guards for error handling:
isNotionClientError(error)- Check if error is any SDK errorisHTTPResponseError(error)- Check if error is an HTTP response error (has status, headers, body)APIResponseError.isAPIResponseError(error)- Check for API-specific errors
Two utilities in src/helpers.ts:
iteratePaginatedAPI()- Async iterator for memory-efficient paginationcollectPaginatedAPI()- Collects all results into array (use for small datasets)
Both accept a list function and parameters, automatically handling start_cursor/next_cursor.
Configurable logging system (src/logging.ts):
- Four levels: DEBUG, INFO, WARN, ERROR (via
LogLevelenum) - Default: WARN level to console
- Custom loggers via
loggeroption (receives level, message, extraInfo) - Debug mode logs full request/response bodies
src/api-endpoints.ts- Auto-generated from API spec (see file header)build/directory - Compiled output
- NO semicolons (enforced by Prettier)
- NO redundant comments - Only add comments explaining "why", not "what"
- NO
as any- Use type guards fromsrc/type-utils.ts - Comment length: max 80 characters per line
- Use CommonJS (
require/module.exports) not ES6 imports
The linter runs cspell for spell checking. Avoid non-dictionary terms in code:
- Use "back-off" instead of "back off" (single word)
- Use "parsable" instead of "parse able" variants
- Prefer standard English words in method names and comments
- Always run
npm run build && npm testbefore committing - Add tests for new functionality in
test/ - CI validates on Node.js 18, 19, 20, 22
npm run prepublishOnly # Runs: checkLoggedIn && lint && testsrc/Client.ts- Main client implementation with all endpoint namespaces and retry logicsrc/index.ts- Public API surface (all exports)src/api-endpoints.ts- Generated API types and endpoint descriptorssrc/errors.ts- Error types and error handling utilitiessrc/helpers.ts- Pagination utilities and type guardssrc/type-utils.ts- TypeScript type guards and utilitiessrc/logging.ts- Logging systemsrc/utils.ts- Internal utilities (pick, isObject)src/fetch-types.ts- Fetch API type definitions (usesunknownfor headers to support various fetch implementations)
- Implement in appropriate source file
- Add exports to
src/index.ts - Add tests in
test/ - Run
npm run build && npm test - Run
npm run lintto validate formatting and spelling
- API endpoint changes must come from upstream (api-endpoints.ts is generated)
- New endpoint types are automatically available once api-endpoints.ts is regenerated
- Wire up new endpoints in Client.ts following existing patterns
If adding response type discriminators, add type guard functions to src/helpers.ts following the isFullX() pattern and export from src/index.ts.