Hi everyone,

I’m currently building NotionManager, a local-first desktop app designed to snapshot Notion workspaces into a block-based local DB for high-fidelity offline viewing.

While full snapshotting works beautifully, I’ve spent weeks trying to implement an incremental backup feature to save users from re-downloading gigabytes of data. After digging deep into the implementation, I’ve hit a wall that isn’t just about rate limits—it’s about fundamental API design flaws.

Here is the engineering reality. I’ve come to the conclusion that a truly reliable incremental backup tool cannot be built on top of the current Notion API. Change my mind.

Here is the breakdown of why it breaks down:

1. The LACK of a Traversal Endpoint

Notion provides no native way to traverse or stream the workspace graph from the root. You cannot ask for a changelog or a delta stream.

2. The Broken last_edited_time Behavior

Every object has a last_edited_time, which sounds promising, but its behavior makes it useless for mutation detection:

• Minute-level Resolution: The timestamp resolution is capped at the minute level. For rapid programmatic changes or busy workspaces, this granularity is blind to rapid successive mutations.
• No Topology Bubble-up: Updating a child block or a sub-page does not bubble up and update the last_edited_time of the parent page. The parent remains frozen in time. Worse, this behavior is completely undocumented and requires constant trial-and-error to map out.

3. The Entrance Problem (No Global Catalog)

Objects do maintain parent topology information, which is great, but you still need a global entry point to start recursing down.

4. The Hack: Forcing /v1/search into a Global Router

The only global entry point available is the /v1/search endpoint. It guarantees that any object explicitly shared with the integration will show up. This works as a baseline for full backups, allowing us to maintain a global flat list of entry points (pages and databases).

5. Why Incremental Discovery is an Illusion

For incremental backups, you must discover newly created objects. Currently, there is no reliable mechanism for this. With precise tuning, /v1/search seems to surfaced new objects eventually. But here is the catch: it offers zero API contract guarantees. Search indexes can be delayed, rate-limited, or completely omit items without violating the endpoint’s design contract (since it’s meant for humans searching keywords, not machines syncing state).

The Bitter Conclusion

If we blindly trust that the /v1/search index behavior remains consistent, we can hypothetically discover new objects, combine them with our previous global list, and check individual last_edited_time stamps to build a "near-usable" sync.

Unfortunately, "near-usable" is completely unacceptable for a backup solution.

Because the search API offers no contractual guarantees, the sync engine could quietly miss a newly created sub-page, fail silently, and cause catastrophic data loss without the user or the app ever knowing.

Therefore, my architectural conclusion is absolute: Under the current API design, a reliable incremental backup for Notion is impossible. You either pull the entire world every time via full snapshots, or you accept silent corruption.

To anyone who has wrestled with Notion's data model or built sync engines on top of legacy web APIs: Am I missing a hidden workaround, or have you all forced your users into mandatory full snapshots as well?

Would love to hear your thoughts or architectural post-mortems on this!

Hi everyone,

Thank you for your interest in NotionManager – a tool that helps you back up your entire Notion workspace to local storage, losslessly, and browse it offline.

After the last community feedback post, quite a few people expressed interest, and many of you even signed up on the Waitlist (thank you!). Shortly after, I released the first usable Alpha to demonstrate a few core ideas:

1. Workspace backup based on Notion Connections
2. Local offline browsing
3. Optional incremental backup support

In the new Alpha, several areas have been significantly improved:

1. Much faster backup speed External files can now be downloaded in parallel, and Notion data is processed as efficiently as possible within API rate limits. Deduplication has also been improved – identical elements are stored only once.

2. Richer rendering support Most text properties, common database views, column layouts, and more are now supported.

Notion vs NotionManager – Offline Render Comparison

Notion is known for its rich display capabilities, and fully replicating all of them requires a massive amount of detail work – especially in areas not fully covered by the API or its documentation.

Our approach is: get the data accurate and complete first. This means that when we improve rendering in the future, you won’t need to re‑back up anything.

3. Incremental backup is temporarily disabled Getting this right is tricky. The Notion API doesn’t clearly expose whether a change to one element affects the last‑edited timestamp of its parent – and this behavior can change without notice.

We need to be cautious: correctness first, optimization later. In fact, I’m working on building an open‑source validation suite for Notion page behavior to serve as a foundation for future work. I believe this would be valuable for all Notion backup providers – if someone is already doing this (or planning to), please let me know.

4. The database backend has been upgraded to native SQLite3 The storage layer is now more stable and efficient.

5. Major architectural refactoring Especially around error handling, crash‑safe data handling, and backup job tracking.

In the age of vibe coding, this might sound old‑fashioned – but trust me, for a backup tool, nothing is worse than incomplete or inconsistent data.

I’ve built enterprise‑grade backup software before, and I know firsthand that data unavailability and data loss are simply unacceptable for any data‑centric service.

Please give me the time to get the fundamentals right and stable.

Once the foundation is solid, the release cadence will accelerate.

If you haven’t already, head over to the Waitlist (https://tally.so/forms/81EEaA/insights) – you’ll still have a chance to lock in 50% off the launch price.

Thank you for your feedback, and even more, for supporting a better backup system for Notion.

- bz

Hi everyone,

Like many of you, I love Notion's interface, but the thought of having all knowledge, documentation, and databases sitting entirely on cloud only always gave me a bit of anxiety. What if the server goes down? What if I'm offline?

A friend of mine had the same concern, so as a solo developer, I built a lightweight, no-nonsense tool for him. It does exactly two things, and it does them locally:

• One-click backup: Downloads Notion workspace data straight to your local machine. I am implementing incremental backup support right now so that even a big knowledge asset can be snapshot-updated easily.
• Local Viewer: Browse pages and databases completely offline with a clean UI. I expect it to provide the same interactive feel as Notion does.

No fancy features, no AI, no bloated dashboards, and no third-party SaaS databases. Just reliable backups and read-only local browsing so far.

I’m thinking about whether this is a common issue and would like to hear from the community. I may transform it into a public tool if needed.

Thank you!

PS, I have not a chance to take a video yet. I want to post some snapshots but reddit thinks it break community rules, sigh! tell me if you are interested in the tool.

PS, you can register your name at https://tally.so/r/81EEaA so that I can update to you directly when runable demo come out.

PS, a simple demo ready. the backup browsing need lots of refine yet.

https://reddit.com/link/1u6633l/video/cl5tftbvun7h1/player