I see that the individual block types have been removed and replaced with a large generic union on the responses of some queries.

for example (have removed some properties for clarity):

ListBlockChildrenResponse["results"] = Array<
           {
              type: "paragraph";
              ...stuff
             } | { 
              type: "heading_1";
             ...stuff

... and so on

So a Block I guess can now be represented by:

export type Block = ListBlockChildrenResponse["results"][0]

The same goes for the Database type

export type Database = QueryDatabaseResponse["results"][0]

But when I have a database that has properties on it like "Name" or "Slug", how do I correctly extend the properties type so that its possible to access it without TS complaining, before I could do something like:

const name = (database.properties.Name as TitlePropertyValue).title[0].plain_text

But now that the TitlePropertyValue type doesn't exist, not really sure to handle the custom properties?

Any ideas?

Thanks

I am trying to talk to the notion api via a webpage, but it is getting blocked by the browser. I think this should be possible to fix on the server side by adding the "Access-Control-Allow-Origin: *" in the reply header.

A current workaround for this is to run the browser with CORS check disabled.

Report bugs here only for the Node JavaScript library.

If you're having problems using Notion's API, or have any other feedback about the API including feature requests for the JavaScript library, please email support at [email protected].

Describe the bug Currently the SDK doesn't give much outside of an id in the property. Equivalent request in Postman, has detailed JSON with id, type and content.

To Reproduce Node version: v16.14.2 Notion JS library version: v2.0.0

Steps to reproduce the behavior:

const { Client } = require("@notionhq/client");

const notion = new Client({
  auth: process.env.NOTION_API_KEY
});

(async () => {
  const databaseId = process.env.NOTION_DATABASE_ID;
  const response = await notion.databases.query({
    database_id: databaseId,
    filter: {
      property: "Tags",
      multi_select: {
        contains: "italian",
      },
    },
  });

  console.log(response.results[0].properties);
  console.log(response.results[1].properties);

  process.exit();
})();

Expected behavior Content inside database item properties

Screenshots

• [x] Adds support for new block types (embed, image, video, file, pdf, bookmark)
• [x] Adds support for listing urls when fetching file properties
• [x] Adds support for updating file property values
• [x] Adds support for retrieving, setting, and updating page/database icons
• [x] Adds support for retrieving, setting, and updating page/database covers

Title says it all. There are types like RichTextItemResponse and BlockObjectResponse that would be useful to have so we could create utils in our integrations that perform type checking

Describe the bug When I upgrade from v0.4.9 to v0.4.11, I get type errors in my code that look like this

Property 'properties' does not exist on type '{ object: "page"; id: string; }'

Seems like the recent type updates in the api-endpoints.ts file has new types that look similar to the following that cause the error:

{
    ...
        object: "page";
        id: string;
        created_time: string;
        last_edited_time: string;
        archived: boolean;
        url: string;
    } | {
        object: "page";
        id: string;
    }>;

and

{
    ...
} | {
    object: "block";
    id: string;
}

To Reproduce Node version: v16.13.0 Notion JS library version: v0.4.11

Steps to reproduce the behaviour: Try running a similar code snippet with v0.4.11 to make a notion query and parse some data and you will notice item.properties throws a ts(2339) error. So will item.icon.

export async function getBookmarks() {
  const { results } = await notion.databases.query({
    database_id: process.env.NOTION_BOOKMARKS_DATABASE ?? "",
    filter: {
      property: "Status",
      select: {
        equals: "Published",
      },
    },
  });
  return results.map((item) => {
    const properties = item.properties;
    return {
      id: item.id,
      emoji: item?.icon?.type === "emoji" ? item.icon.emoji : "",
      createdAt:
        properties.Created.type === "created_time"
          ? properties.Created.created_time
          : "",
      name:
        properties.Name.type === "title"
          ? properties.Name.title[0].plain_text
          : "",
      type: properties.Type.type === "select" ? properties.Type.select : "",
      url: properties.URL.type === "url" ? properties.URL.url : "",
    } as Bookmark;
  });
}

Expected behaviour This wasn't the behaviour prior to the upgrade. v0.4.9 didn't throw these errors. These extra types seem redundant and don't look like they belong there. Why would you have a page or block type that only has an id and no other metadata (created_time, URL, etc)?

Is this something that needs to be fixed? Is there a way to work around this?

Screenshots

Report bugs here only for the Node JavaScript library.

If you're having problems using Notion's API, or have any other feedback about the API including feature requests for the JavaScript library, please email support at [email protected].

Describe the bug A clear and concise description of what the bug is. Upon upgrading to 0.4.0, typings have gone crazy. api-types is now replaced by api-endpoints. The problem is the type for each Block is now gone. To Reproduce Node version: 14 Notion JS library version: 0.4.0

Steps to reproduce the behavior:

Expected behavior Typing for each Block type should be defined separately and exposed.

Screenshots Like trying to get HeadingOneBlock out of this type union is a nightmare

Additional context Add any other context about the problem here.

Description

• [x] closes #14
• [x] Update each example to use named methods rather than notion.request
  • [x] examples/github-issue-sync
  • [x] examples/database-update-send-email
  • [x] examples/generate-random-data (already implemented named methods)

Report bugs here only for the Node JavaScript library.

If you're having problems using Notion's API, or have any other feedback about the API including feature requests for the JavaScript library, please email support at [email protected].

Describe the bug When I query a page using the v2.0.0 SDK and above, the responses do not include property values. Just an ID. There's no indication in the documentation that an extra step is required to fetch the page property values.

I'm trying to paginate through a database, but each row contains no property values. It also happens retrieving a single page. I'll write a minimal example:

To Reproduce Node version: 16.14.0 Notion JS library version: 1.0.4

spec.js:

const { Client } = require('@notionhq/client')

const notion = new Client({ auth: process.env.NOTION_TOKEN })
const page_id = process.env.NOTION_PAGE_ID

notion.pages.retrieve({ page_id }).then((page) => {
  console.log(page.properties)
})

Result (SDK v1.0.4):

{
  Case: { id: '%3BVfS', type: 'files', files: [] },
  Guitar: { id: '%3DkPp', type: 'files', files: [ [Object] ] },
  'Made In': { id: 'O%7BaE', type: 'rich_text', rich_text: [ [Object] ] },
  State: { id: 'PQJs', type: 'rich_text', rich_text: [] },
  Serial: { id: 'WuDR', type: 'rich_text', rich_text: [ [Object] ] },
  Tags: { id: 'ii%5E%7C', type: 'multi_select', multi_select: [ [Object] ] },
  Name: { id: 'title', type: 'title', title: [ [Object] ] }
}

Result (v2.0.0):

{
  Case: { id: '%3BVfS' },
  Guitar: { id: '%3DkPp' },
  'Made In': { id: 'O%7BaE' },
  State: { id: 'PQJs' },
  Serial: { id: 'WuDR' },
  Tags: { id: 'ii%5E%7C' },
  Name: { id: 'title' }
}

Steps to reproduce the behavior: Run the above script and compare v1.0.4 to 2.0.0 output.

Expected behavior The SDK should include Notion properties on simple queries.

If this is intentional behaviour: The documentation should make this very obvious! How do I retrieve a full database in the v2 SDK?

What

• Rework error types. This is a breaking change.
• replace got with node-fetch, similar to whatwg-fetch.
• Allow pluggable fetch function that supports the subset of fetch options compatible with node-fetch & browser fetch
• use package.json version in user-agent header

Why

• Partially addresses #60, although does not provide a solution for security or CORS.
• Because we no longer import big expensive dependencies, consumers will be able to subclass Client to override the request method to implement proxying requests via the server.

Remarks

• This adds some new code, but also removes some got-specific code of about the same length. The trade-off seems worth it.
• I haven't tested this code yet, and unfortunately we don't have any tests for Client.prototype.request. Being able to inject our own fetch implementation should make writing tests easier
• I plan to integration test the branch by integrating it into my project https://github.com/justjake/notrition in the coming days, but don't expect rapid movement here -- I'm doing this work as a hobbyist who wants isomorphic fetch, not as a Notion employee.

Describe the bug

The QueryDatabaseResponse type as defined in api-endpoints.d.ts does not expose the properties field on the objects within the results array. The results array is typed as a large union which does not allow type discrimination to narrow the result type.

To Reproduce Node version: 14 Notion JS library version: 1.0.4 Typescript version: 4.4.5

This snippet will generate the type issue - this is intended for reproduction of the typing issue, and not as validly executable code.

import { Client } from '@notionhq/client';

const client = {} as Client;
const data = await client.databases.query({ database_id: 'foo' });
const resultObject = data.results[0];
if (resultObject.object === 'page') { 
  resultObject.properties; // <-- a type error is generated here
}

TS error:

TS2339: Property 'properties' does not exist on type '{ parent: { type: "database_id"; database_id: string; } | { type: "page_id"; page_id: string; } | { type: "workspace"; workspace: true; }; properties: Record<string, { type: "number"; number: number | null; id: string; } | ... 17 more ... | { ...; }>; ... 9 more ...; url: string; } | { ...; }'.   Property 'properties' does not exist on type '{ object: "page"; id: string; }'.

Expected behavior

I would expect optional properties that are available on the returned results objects to be typed as optional, or a field to be present which can be used to discriminate the union, and allow access to the properties field.

Additional context

The type is defined as such:

export declare type QueryDatabaseResponse = {
    type: "page";
    page: EmptyObject;
    object: "list";
    next_cursor: string | null;
    has_more: boolean;
    results: Array<{
        parent: {
            type: "database_id";
            database_id: IdRequest;
        } | {
            type: "page_id";
            page_id: IdRequest;
        } | {
            type: "workspace";
            workspace: true;
        };
        properties: Record<string, { /** truncated here */}>;
        /** removed some properties here for brevity */
        object: "page";
        id: string;
        created_time: string;
        last_edited_time: string;
        archived: boolean;
        url: string;
    } | {
        object: "page";
        id: string;
    }>;
};

I believe that the last union is the issue - as it has the effect of removing all the previously declared types, and because object: "page"; is shared by both types in this union there is no property that can be used as a discriminator, in order to get access to the other fields.

Two solutions that I see:

1. add a type discriminator to the response
2. modify this type such that fields that may be optional are defined as optional. For example:

export declare type QueryDatabaseResponse = {
    type: "page";
    page: EmptyObject;
    object: "list";
    next_cursor: string | null;
    has_more: boolean;
    results: Array<{
        object: "page";
        id: string;
        parent?: {
            type: "database_id";
            database_id: IdRequest;
        } | {
            type: "page_id";
            page_id: IdRequest;
        } | {
            type: "workspace";
            workspace: true;
        };
        properties?: Record<string, { /** truncated here */}>;
        /** removed some properties here for brevity */
        created_time?: string;
        last_edited_time?: string;
        archived?: boolean;
        url?: string;
    }>;
};
    

I think 2 is simpler as it does not require any changes to the underlying api - whereas 1 may require an extra field be returned to allow type discrimination.

This example can be used as a start point for anyone interested on syncing GitHub Projects (not-classic) with Notion. It's necessary to access GitHub GraphQL API for that.

I hope someone continues this work and creates a Notion plugin for that purpose.

Attempting to deploy a Next.js 13 project that uses the Notion client is failing when deploying to Vercel. It works locally.

Error:

I think Next.js 13 overrides the native fetch, so maybe that's related to the issue?

To Reproduce Node version: Tested 16.x and 18.x Notion JS library version: 2.2.2

Seems the .vscode directory can be ignored. We already have .cspell.json in our project and they support .cspell.json as the configuration file in VS Code:

See https://github.com/streetsidesoftware/vscode-spell-checker/blob/add7ae9b37b7d02eadfbd2788ab0b0d6699e09d6/packages/client/src/settings/CSpellSettings.ts#L11-L13.

On the other hand, ignoring the .vscode directory can let developers put their editor settings. They can decide to enable or disable specific extension settings for specific projects.

Currently, we don't have other editor settings like .vscode/launch.json, .vscode/tasks.json, etc. So it's OK to ignore the whole directory.

We could change the rule if we need to put some other project-level configuration files in the .vscode directory in the future.

Report bugs here only for the Node JavaScript library.

If you're having problems using Notion's API, or have any other feedback about the API including feature requests for the JavaScript library, please email support at [email protected].

Describe the bug A clear and concise description of what the bug is.

To Reproduce Node version: 16 Notion JS library version: 2.2.1

Steps to reproduce the behavior:

Notion number formulas always return 0 in queries:

1. Create a database (monthly summary)
2. Create database (expenses)
3. Create relation between both database (monthly expenses)
4. create rollup of type sum on monthly summary database to sum all linked expenses amounts
5. create formula field on monthly summary database that calculate (income - expenses)

Expected behavior A clear and concise description of what you expected to happen. Notion JS SDK returns the calculated values by the formula

Screenshots Please include any screenshots that help explain your problem.

Additional context Add any other context about the problem here. I double checked that I added the integration to both databases

Report bugs here only for the Node JavaScript library.

If you're having problems using Notion's API, or have any other feedback about the API including feature requests for the JavaScript library, please email support at [email protected].

Describe the bug When using the autogenerated types, i'm seeing a few issues. there appears to be a lot of inconsistency inbetween types, and they frequently do stuff like:

type?: "file"

which is saying "if the following string happens to be null it's ok" but then declaring it voids that ?.

To that end, I wanted to present a slightly more approachable set of types. I'm looking to leverage enums, inheritance, and all the good stuff from latest TS

To Reproduce Node version: any Notion JS library version: any

Steps to reproduce the behavior:

Expected behavior meaningful and traceable types to help me debug

Screenshots with current wacky types i'm doing stuff like reexporting, but because of the type build, the TS language server doesn't understand the innerconnects so you get types like this

which leads to comical issues like this:

literally saying the types aren't compatible for a derived block request and a block request (which isn't currently exported)

Additional context to help illustrate, here is the api endpoints rewritten to have an ImageUploadRequest Type. this also allows you to access an object via the key as a string and it works!

for a quick example:

const someImgRequestFile: ImageReq<FileReq> = {
    type: AllTypesOfPayload.image,
    image: {
        type: AllTypesOfPayload.file,
        external: {
            url: ""
        },
        caption: ['']
    }
}

throws the type error"

Type '{ type: AllTypesOfPayload.file; external: { url: string; }; caption: string[]; }' is not assignable to type 'FileReq'.
  Object literal may only specify known properties, and 'external' does not exist in type 'FileReq'.ts(2322)

which actually allows someone to debug the missing bit! no extraneous info, just the core issue.

/**
 * Utilities for working with typescript types
 */
/**
 * Assert U is assignable to T.
 */
export type Assert<T, U extends T> = U

enum AllTypesOfPayload {
    person = "person",
    bot = "bot",
    user = "user",
    string = "string",
    boolean = "boolean",
    text = "text",
    template_mention_date = "template_mention_date",
    template_mention_user = "template_mention_user",
    mention = "mention",
    template_mention = "template_mention",
    equation = "equation",
    emoji = "emoji",
    single_property = "single_property",
    dual_property = "dual_property",
    paragraph = "paragraph",
    heading_1 = "heading_1",
    heading_2 = "heading_2",
    heading_3 = "heading_3",
    bulleted_list_item = "bulleted_list_item",
    numbered_list_item = "numbered_list_item",
    quote = "quote",
    to_do = "to_do",
    toggle = "toggle",
    template = "template",
    synced_block = "synced_block",
    child_page = "child_page",
    child_database = "child_database",
    code = "code",
    callout = "callout",
    divider = "divider",
    breadcrumb = "breadcrumb",
    table_of_contents = "table_of_contents",
    column_list = "column_list",
    column = "column",
    link_to_page = "link_to_page",
    comment_id = "comment_id",
    table = "table",
    table_row = "table_row",
    embed = "embed",
    bookmark = "bookmark",
    image = "image",
    video = "video",
    pdf = "pdf",
    audio = "audio",
    external = "external",
    file = "file",
    link_preview = "link_preview",
    url = "url",
    select = "select",
    multi_select = "multi_select",
    status = "status",
    email = "email",
    phone_number = "phone_number",
    checkbox = "checkbox",
    files = "files",
    created_by = "created_by",
    created_time = "created_time",
    last_edited_by = "last_edited_by",
    last_edited_time = "last_edited_time",
    formula = "formula",
    page_id = "page_id",
    block_id = "block_id",
    property_item = "property_item",
    title = "title",
    rich_text = "rich_text",
    people = "people",
    relation = "relation",
    rollup = "rollup",
    number = "number",
    date = "date",
    array = "array",
    unsupported = "unsupported",
    incomplete = "incomplete",
    workspace = "workspace",
    block = "block",
    page = "page",
    database = "database",
    page_or_database = "page_or_database",
    comment = "comment",
}

type IsomorphicRequest<TypeOfCall extends AllTypesOfPayload, Payload> = Record<TypeOfCall, Payload> & {
    type: TypeOfCall
}

type Caption = { caption: string[] }

type ExternalReq = IsomorphicRequest<AllTypesOfPayload.external, { url: string }> & Caption

type FileReq = IsomorphicRequest<AllTypesOfPayload.file, { url: string, expiry_time: string }>

type ImageReq<T extends ExternalReq | FileReq> = IsomorphicRequest<AllTypesOfPayload.image, T>

const someImgRequestExt: ImageReq<ExternalReq> = {
    type: AllTypesOfPayload.image,
    image: {
        type: AllTypesOfPayload.external,
        external: {
            url: ""
        },
        caption: ['']
    }
}

const someImgRequestFile: ImageReq<FileReq> = {
    type: AllTypesOfPayload.image,
    image: {
        type: AllTypesOfPayload.file,
        external: {
            url: ""
        },
        caption: ['']
    }
}