[Fix] No Endpoints for FetchBlocks (syncRecordValues)

[kibum99]

Summary

This PR updates notion.ts’s fetchBlocks to stop calling the deprecated endpoint POST https://www.notion.so/api/v3/syncRecordValues and use POST https://www.notion.so/api/v3/getRecordValues instead. Because the response shape from getRecordValues differs slightly, the implementation now normalizes the payload so the rest of the codebase can consume it without changes. This resolves runtime errors occurring on v1/page/:pageId, which depends on fetchBlocks.

Background & Problem

•	The Notion internal API endpoint syncRecordValues no longer exists.
•	Actual response from the old endpoint: "This endpoint doesn't exist anymore! What are you doing? Email [email protected]"
•	As a result, any call path that triggers fetchBlocks (e.g., GET v1/page/:pageId) fails.

What’s changed

•	Endpoint switch: fetchBlocks now calls POST https://www.notion.so/api/v3/getRecordValues.
•	Response normalization: Added a small transformation layer to adapt getRecordValues’s response to the structure previously consumed by our code (e.g., mapping record containers to our internal Block model).
•	No API surface change: fetchBlocks(blockList: string[], notionToken?: string) signature and call sites remain the same.
•	Error handling: Updated error messages to clearly report upstream failures from getRecordValues.

Rationale

•	getRecordValues is the closest stable replacement for syncRecordValues for fetching multiple block records by ID.
•	Normalizing at the boundary keeps downstream logic untouched and minimizes the blast radius.

Implementation notes

•	The request still batches by the provided blockList and authenticates using the existing notionToken (if provided).
•	The normalization step handles differences in envelope/field names so that the returned data matches what callers previously expected.
•	No behavior changes are intended beyond fixing the failed requests.

Impact

•	Fixes: v1/page/:pageId no longer errors when loading blocks.
•	Backward compatibility: Callers of fetchBlocks do not need to change anything.
•	Risk: Low. The change is isolated to the HTTP call + shape conversion.

How I tested

1.	Reproduced the failure on the current main branch: invoking any code path that triggers fetchBlocks results in the “endpoint doesn’t exist” message from Notion.
2.	Applied the change and verified:
•	fetchBlocks returns data in the expected internal format.
•	GET v1/page/:pageId succeeds and renders as before.
•	Error paths (invalid token, unknown block IDs) surface clear messages.

Checklist

•	Replaced endpoint in fetchBlocks
•	Added response normalization to preserve existing contract
•	Verified v1/page/:pageId works against getRecordValues
•	Updated inline comments/docstrings

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Preview	Comments	Updated (UTC)
notion-api-worker	Error			Aug 20, 2025 4:56pm

[wJoenn]

@kibum99 I just tried your method in a local script and I'm getting an error 500 on the getRecordValues endpoint

    data: {
      errorId: 'd9c21994-656d-4d83-b14f-96036d58cd2e',
      name: 'DatastoreInfraError',
      debugMessage: 'No postgres config for database spaceShard057',
      message: 'Something went wrong. (500)'
    }

Did you manage to use your script successfully ?

Here's the whole AxiosError in case that helps
error.txt