[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-10255":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":16,"stars7d":17,"stars30d":18,"stars90d":16,"forks30d":16,"starsTrendScore":17,"compositeScore":19,"rankGlobal":10,"rankLanguage":10,"license":20,"archived":21,"fork":21,"defaultBranch":22,"hasWiki":21,"hasPages":21,"topics":23,"createdAt":10,"pushedAt":10,"updatedAt":30,"readmeContent":31,"aiSummary":32,"trendingCount":16,"starSnapshotCount":16,"syncStatus":33,"lastSyncTime":34,"discoverSource":35},10255,"notion-sdk-js","makenotion\u002Fnotion-sdk-js","makenotion","Official Notion JavaScript Client","https:\u002F\u002Fdevelopers.notion.com\u002F",null,"TypeScript",5608,706,111,53,0,1,12,66.25,"MIT License",false,"main",[24,25,26,27,28,29],"api","api-client","javascript","js","notion","typescript","2026-06-12 04:00:49","# Notion SDK for JavaScript\n\n\u003Cimg alt=\"Notion Logo\" src=\"https:\u002F\u002Fwww.notion.so\u002Fimages\u002Fnotion-logo-block-main.svg\" width=\"70\" \u002F>\n\n**A simple and easy to use client for the [Notion API](https:\u002F\u002Fdevelopers.notion.com).**\n\n![Build status](https:\u002F\u002Fgithub.com\u002Fmakenotion\u002Fnotion-sdk-js\u002Factions\u002Fworkflows\u002Fci.yml\u002Fbadge.svg)\n[![npm version](https:\u002F\u002Fbadge.fury.io\u002Fjs\u002F%40notionhq%2Fclient.svg)](https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002F@notionhq\u002Fclient)\n\n## Installation\n\n```bash\nnpm install @notionhq\u002Fclient\n```\n\n[![Open Val Town Template](https:\u002F\u002Fstevekrouse-badge.web.val.run\u002F?3)](https:\u002F\u002Fwww.val.town\u002Fv\u002Fcharmaine\u002FNotionJsSDK)\n\n## Usage\n\n> [!NOTE]\n> Use Notion's [Getting Started Guide](https:\u002F\u002Fdevelopers.notion.com\u002Fdocs\u002Fgetting-started) to get set up to use Notion's API.\n\nImport and initialize a client using an **integration token** or an OAuth **access token**.\n\n```js\nconst { Client } = require(\"@notionhq\u002Fclient\")\n\n\u002F\u002F Initializing a client\nconst notion = new Client({\n  auth: process.env.NOTION_TOKEN,\n})\n```\n\nMake a request to any Notion API endpoint.\n\n```js\n;(async () => {\n  const listUsersResponse = await notion.users.list({})\n})()\n```\n\n> [!NOTE]\n> See the complete list of endpoints in the [API reference](https:\u002F\u002Fdevelopers.notion.com\u002Freference).\n\nEach method returns a `Promise` that resolves the response.\n\n```js\nconsole.log(listUsersResponse)\n```\n\n```ts\n{\n  results: [\n    {\n      object: \"user\",\n      id: \"d40e767c-d7af-4b18-a86d-55c61f1e39a4\",\n      type: \"person\",\n      person: {\n        email: \"avo@example.org\",\n      },\n      name: \"Avocado Lovelace\",\n      avatar_url:\n        \"https:\u002F\u002Fsecure.notion-static.com\u002Fe6a352a8-8381-44d0-a1dc-9ed80e62b53d.jpg\",\n    },\n    \u002F\u002F ...\n  ]\n}\n```\n\nEndpoint parameters are grouped into a single object. You don't need to remember which parameters go in the path, query, or body.\n\n```js\nconst myPage = await notion.dataSources.query({\n  data_source_id: \"897e5a76-ae52-4b48-9fdf-e71f5945d1af\",\n  filter: {\n    property: \"Landmark\",\n    rich_text: {\n      contains: \"Bridge\",\n    },\n  },\n})\n```\n\n### Handling errors\n\nIf the API returns an unsuccessful response, the returned `Promise` rejects with a `APIResponseError`.\n\nThe error contains properties from the response, and the most helpful is `code`. You can compare `code` to the values in the `APIErrorCode` object to avoid misspelling error codes.\n\n```js\nconst { Client, APIErrorCode } = require(\"@notionhq\u002Fclient\")\n\ntry {\n  const notion = new Client({ auth: process.env.NOTION_TOKEN })\n  const myPage = await notion.dataSources.query({\n    data_source_id: dataSourceId,\n    filter: {\n      property: \"Landmark\",\n      rich_text: {\n        contains: \"Bridge\",\n      },\n    },\n  })\n} catch (error) {\n  if (error.code === APIErrorCode.ObjectNotFound) {\n    \u002F\u002F\n    \u002F\u002F For example: handle by asking the user to select a different data source\n    \u002F\u002F\n  } else {\n    \u002F\u002F Other error handling code\n    console.error(error)\n  }\n}\n```\n\n### Logging\n\nThe client emits useful information to a logger. By default, it only emits warnings and errors.\n\nIf you're debugging an application, and would like the client to log response bodies, set the `logLevel` option to `LogLevel.DEBUG`.\n\n```js\nconst { Client, LogLevel } = require(\"@notionhq\u002Fclient\")\n\nconst notion = new Client({\n  auth: process.env.NOTION_TOKEN,\n  logLevel: LogLevel.DEBUG,\n})\n```\n\nYou may also set a custom `logger` to emit logs to a destination other than `stdout`. A custom logger is a function which is called with 3 parameters: `logLevel`, `message`, and `extraInfo`. The custom logger should not return a value.\n\n### Client options\n\nThe `Client` supports the following options on initialization. These options are all keys in the single constructor parameter.\n\n| Option      | Default value               | Type           | Description                                                                                                                                                  |\n| ----------- | --------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| `auth`      | `undefined`                 | `string`       | Bearer token for authentication. If left undefined, the `auth` parameter should be set on each request.                                                      |\n| `logLevel`  | `LogLevel.WARN`             | `LogLevel`     | Verbosity of logs the instance will produce. By default, logs are written to `stdout`.                                                                       |\n| `timeoutMs` | `DEFAULT_TIMEOUT_MS`        | `number`       | Number of milliseconds to wait before emitting a `RequestTimeoutError`                                                                                       |\n| `baseUrl`   | `DEFAULT_BASE_URL`          | `string`       | The root URL for sending API requests. This can be changed to test with a mock server.                                                                       |\n| `logger`    | Log to console              | `Logger`       | A custom logging function. This function is only called when the client emits a log that is equal or greater severity than `logLevel`.                       |\n| `agent`     | Default node agent          | `http.Agent`   | Used to control creation of TCP sockets. A common use is to proxy requests with [`https-proxy-agent`](https:\u002F\u002Fgithub.com\u002FTooTallNate\u002Fnode-https-proxy-agent) |\n| `retry`     | See [constants](#constants) | `RetryOptions` | Configuration for automatic retries on rate limits (429) and server errors (500, 503). See [Automatic retries](#automatic-retries) below.                    |\n\n### Automatic retries\n\nThe client automatically retries requests that fail due to rate limiting or transient server errors. By default, it will retry up to 2 times using exponential back-off with jitter.\n\n**Retryable errors:**\n\n- `rate_limited` (HTTP 429) - Too many requests; retried for all HTTP methods\n- `internal_server_error` (HTTP 500) - Server error; retried only for GET and DELETE\n- `service_unavailable` (HTTP 503) - Service temporarily unavailable; retried only for GET and DELETE\n\nServer errors (500, 503) are only retried for idempotent HTTP methods (GET, DELETE) to avoid duplicate side effects. Rate limits (429) are retried for all methods since the server explicitly asks clients to retry.\n\n**Retry behavior:**\n\n- Uses exponential back-off: delays increase with each retry attempt\n- Respects the `Retry-After` header when present (both delta-seconds and HTTP-date formats)\n- Adds random jitter to prevent thundering herd problems\n\n**Configuration:**\n\n```js\nconst notion = new Client({\n  auth: process.env.NOTION_TOKEN,\n  retry: {\n    maxRetries: 5, \u002F\u002F Maximum retry attempts (default: 2)\n    initialRetryDelayMs: 500, \u002F\u002F Initial delay between retries (default: 1000ms)\n    maxRetryDelayMs: 60000, \u002F\u002F Maximum delay between retries (default: 60000ms)\n  },\n})\n```\n\nTo disable automatic retries:\n\n```js\nconst notion = new Client({\n  auth: process.env.NOTION_TOKEN,\n  retry: false,\n})\n```\n\n### Constants\n\nThe SDK exports named constants for all default values used by the client, as well as useful Notion-specific values. You can import them directly:\n\n```js\nconst {\n  DEFAULT_BASE_URL, \u002F\u002F \"https:\u002F\u002Fapi.notion.com\"\n  DEFAULT_TIMEOUT_MS, \u002F\u002F 60_000\n  DEFAULT_MAX_RETRIES, \u002F\u002F 2\n  DEFAULT_INITIAL_RETRY_DELAY_MS, \u002F\u002F 1_000\n  DEFAULT_MAX_RETRY_DELAY_MS, \u002F\u002F 60_000\n  MIN_VIEW_COLUMN_WIDTH, \u002F\u002F 32\n} = require(\"@notionhq\u002Fclient\")\n```\n\n`MIN_VIEW_COLUMN_WIDTH` is the minimum width (in pixels) that a table column can have in the Notion UI. Set a property's `width` to this value when creating or updating a view to make a column appear collapsed -- useful for checkbox or status-as-checkbox columns:\n\n```js\nawait notion.views.create({\n  database_id: databaseId,\n  name: \"My view\",\n  type: \"table\",\n  configuration: {\n    table: {\n      properties: [\n        {\n          property_id: checkboxPropId,\n          visible: true,\n          width: MIN_VIEW_COLUMN_WIDTH,\n        },\n      ],\n    },\n  },\n})\n```\n\n### TypeScript\n\nThis package contains type definitions for all request parameters and responses,\nas well as some useful sub-objects from those entities.\n\nBecause errors in TypeScript start with type `any` or `unknown`, you should use\nthe `isNotionClientError` type guard to handle them in a type-safe way. Each\n`NotionClientError` type is uniquely identified by its `error.code`. Codes in\nthe `APIErrorCode` enum are returned from the server. Codes in the\n`ClientErrorCode` enum are produced on the client.\n\n```ts\ntry {\n  const response = await notion.dataSources.query({\n    \u002F* ... *\u002F\n  })\n} catch (error: unknown) {\n  if (isNotionClientError(error)) {\n    \u002F\u002F error is now strongly typed to NotionClientError\n    switch (error.code) {\n      case ClientErrorCode.RequestTimeout:\n        \u002F\u002F ...\n        break\n      case APIErrorCode.ObjectNotFound:\n        \u002F\u002F ...\n        break\n      case APIErrorCode.Unauthorized:\n        \u002F\u002F ...\n        break\n      \u002F\u002F ...\n      default:\n        \u002F\u002F you could even take advantage of exhaustiveness checking\n        assertNever(error.code)\n    }\n  }\n}\n```\n\n#### Type guards\n\nThere are several [type guards](https:\u002F\u002Fwww.typescriptlang.org\u002Fdocs\u002Fhandbook\u002Fadvanced-types.html#type-guards-and-differentiating-types)\nprovided to distinguish between full and partial API responses.\n\n| Type guard function      | Purpose                                                                                  |\n| ------------------------ | ---------------------------------------------------------------------------------------- |\n| `isFullPage`             | Determine whether an object is a full `PageObjectResponse`                               |\n| `isFullBlock`            | Determine whether an object is a full `BlockObjectResponse`                              |\n| `isFullDataSource`       | Determine whether an object is a full `DataSourceObjectResponse`                         |\n| `isFullPageOrDataSource` | Determine whether an object is a full `PageObjectResponse` or `DataSourceObjectResponse` |\n| `isFullUser`             | Determine whether an object is a full `UserObjectResponse`                               |\n| `isFullComment`          | Determine whether an object is a full `CommentObjectResponse`                            |\n\nHere is an example of using a type guard:\n\n```typescript\nconst fullOrPartialPages = await notion.dataSources.query({\n  data_source_id: \"897e5a76-ae52-4b48-9fdf-e71f5945d1af\",\n})\nfor (const page of fullOrPartialPages.results) {\n  if (!isFullPageOrDataSource(page)) {\n    continue\n  }\n  \u002F\u002F The page variable has been narrowed from\n  \u002F\u002F      PageObjectResponse | PartialPageObjectResponse | DataSourceObjectResponse | PartialDataSourceObjectResponse\n  \u002F\u002F to\n  \u002F\u002F      PageObjectResponse | DataSourceObjectResponse.\n  console.log(\"Created at:\", page.created_time)\n}\n```\n\n### Utility functions\n\nThis package also exports a few utility functions that are helpful for dealing with\nany of our paginated APIs.\n\n#### `iteratePaginatedAPI(listFn, firstPageArgs)`\n\nThis utility turns any paginated API into an async iterator.\n\n**Parameters:**\n\n- `listFn`: Any function on the Notion client that represents a paginated API (i.e. accepts\n  `start_cursor`.) Example: `notion.blocks.children.list`.\n- `firstPageArgs`: Arguments that should be passed to the API on the first and subsequent calls\n  to the API, for example a `block_id`.\n\n**Returns:**\n\nAn [async iterator](https:\u002F\u002Fdeveloper.mozilla.org\u002Fen-US\u002Fdocs\u002FWeb\u002FJavaScript\u002FReference\u002FIteration_protocols#the_async_iterator_and_async_iterable_protocols)\nover results from the API.\n\n**Example:**\n\n```javascript\nfor await (const block of iteratePaginatedAPI(notion.blocks.children.list, {\n  block_id: parentBlockId,\n})) {\n  \u002F\u002F Do something with block.\n}\n```\n\n#### `collectPaginatedAPI(listFn, firstPageArgs)`\n\nThis utility accepts the same arguments as `iteratePaginatedAPI`, but collects\nthe results into an in-memory array.\n\nBefore using this utility, check that the data you are dealing with is\nsmall enough to fit in memory.\n\n**Parameters:**\n\n- `listFn`: Any function on the Notion client that represents a paginated API (i.e. accepts\n  `start_cursor`.) Example: `notion.blocks.children.list`.\n- `firstPageArgs`: Arguments that should be passed to the API on the first and subsequent calls\n  to the API, for example a `block_id`.\n\n**Returns:**\n\nAn array with results from the API.\n\n**Example:**\n\n```javascript\nconst blocks = await collectPaginatedAPI(notion.blocks.children.list, {\n  block_id: parentBlockId,\n})\n\u002F\u002F Do something with blocks.\n```\n\n### Custom requests\n\nTo make requests directly to a Notion API endpoint instead of using the pre-built families of methods, call the `request()` method. For example:\n\n```ts\n\u002F\u002F POST \u002Fv1\u002Fcomments\nconst response = await notion.request({\n  path: \"comments\",\n  method: \"post\",\n  body: {\n    parent: { page_id: \"5c6a28216bb14a7eb6e1c50111515c3d\" },\n    rich_text: [{ text: { content: \"Hello, world!\" } }],\n  },\n  \u002F\u002F No `query` params in this example, only `body`.\n})\n\nconsole.log(JSON.stringify(response, null, 2))\n```\n\nThe `notion.request\u003CResponseBody>({...})` method is generic; `ResponseBody` represents the expected type of response object Notion returns for the endpoint you're calling (we don't validate this at runtime; you can pass anything!)\n\n> [!TIP]\n> Usually, making custom requests with `notion.request()` isn't necessary, but can be helpful in some cases, e.g. when upgrading your [Notion API version](https:\u002F\u002Fdevelopers.notion.com\u002Freference\u002Fversioning) incrementally before upgrading your SDK version. For example, if there's a new or renamed endpoint in the new API version that isn't yet available to call via a dedicated method on `Client`.\n>\n> In the above example, the simpler approach is to use `await notion.comments.create()`.\n\nAnother customization you can make is to pass your own `fetch` function to the `Client` constructor. This might be helpful for some execution environments where the default, built-in `fetch` isn't suitable.\n\n## Examples\n\nFor sample code and example projects, see [notion-cookbook](https:\u002F\u002Fgithub.com\u002Fmakenotion\u002Fnotion-cookbook\u002Ftree\u002Fmain\u002Fexamples).\n\n## Requirements and compatibility\n\nThis package supports the following minimum versions:\n\n- Runtime: `node >= 18`\n- Type definitions (optional): `typescript >= 5.9`\n\nEarlier versions may still work, but we encourage people building new applications to upgrade to the current stable.\n\nIn some cases, due to backwards-incompatible changes across [Notion API versions](https:\u002F\u002Fdevelopers.notion.com\u002Freference\u002Fversioning), more recent versions of this SDK don't work well with older API versions:\n\n| Version of JS\u002FTS SDK | Minimum recommended API version |\n| -------------------- | ------------------------------- |\n| v4.0.0 and above     | 2022-06-28                      |\n| v5.0.0 and above     | 2025-09-03                      |\n\nThis SDK supports both `2025-09-03` and `2026-03-11` API versions. The default is `2025-09-03`. To use the newer version, pass it when constructing the client:\n\n```js\nconst notion = new Client({\n  auth: process.env.NOTION_TOKEN,\n  notionVersion: \"2026-03-11\",\n})\n```\n\nKey changes in `2026-03-11`:\n\n- **Block positioning**: The `after` parameter on `appendBlockChildren` is replaced by `position`, which supports `after_block`, `start`, and `end`.\n- **Trash status**: The `archived` field is replaced by `in_trash` on pages, blocks, databases, and data sources.\n- **Block type rename**: The `transcription` block type is renamed to `meeting_notes`.\n\nBoth the old and new field names are available in the SDK's TypeScript types for a smooth migration. Fields from the older version are marked `@deprecated`.\n\nIn these cases, we recommend upgrading your Notion API version header using the `Client()` constructor across all of your requests before upgrading to a newer version of the SDK.\n\n## Contributing\n\nWhile we value open-source contributions to this SDK, most of the client code is generated programmatically from the Notion API specification. Additions made directly to `src\u002Fapi-endpoints.ts` or other generated code would be overwritten upon the next release.\n\nIf you'd like to contribute a feature or fix to the SDK's core functionality, we suggest opening an issue first to discuss it with us. This helps ensure your effort aligns with how the SDK is maintained.\n\nHowever, contributions to documentation (including this README), examples, and bug reports are always welcome and greatly appreciated!\n\n## Getting help\n\nIf you want to submit a feature request for Notion's API, or are experiencing any issues with the API platform, please email us at `developers@makenotion.com`.\n\nTo report issues with the SDK, it is possible to [submit an issue](https:\u002F\u002Fgithub.com\u002Fmakenotion\u002Fnotion-sdk-js\u002Fissues) to this repo. However, we don't monitor these issues very closely. We recommend you reach out to us at `developers@makenotion.com` instead.\n","Notion SDK for JavaScript 是一个用于与 Notion API 交互的官方客户端库。该项目使用 TypeScript 编写，支持通过集成令牌或 OAuth 访问令牌初始化客户端，并提供了一套完整的 API 接口来访问和操作 Notion 中的数据，如用户、页面等。其核心功能包括简化了 API 请求参数的组织方式以及错误处理机制，使得开发者能够更专注于业务逻辑而非底层细节。适用于需要在 Web 应用程序中集成 Notion 功能的各种场景，比如构建自动化工具、同步数据到其他平台或是创建基于 Notion 数据的应用。",2,"2026-06-11 03:27:27","top_topic"]