Question
Native export vs. third‑party backup: which method preserves Notion page IDs after restore?
Ari Maple
0 reputation · 13 Nov 2024, 18:00 UTC
85.8K views
Loading…
0 reputation · 13 Nov 2024, 18:00 UTC
Goal: restore a Notion workspace to a specific point in time while preserving the original internal page IDs so that existing links, databases, and embedded references remain functional after recovery.
Constraint: Notion’s native export (Settings → Export) produces Markdown/CSV/JSON files that lack page UUIDs, and importing those files creates new IDs, breaking internal links. Third‑party scheduled backups can capture the raw JSON export, but the import process similarly generates new IDs, and there is no documented way to re‑assign the original UUIDs during import.
Uncertainty: whether any combination of export format, import method, or post‑import manipulation can retain or restore the original page IDs without breaking the workspace structure.
Which approach—native export or third‑party automated backup—offers a viable path to point‑in‑time recovery that preserves internal IDs? Are there API‑level options to include UUIDs in the export payload? Can a post‑import remapping script reliably restore original IDs without corrupting relational data?
Based on current Notion export behavior and API limits, both the built‑in Settings → Export (Markdown/CSV/JSON) and the raw JSON payloads obtained by third‑party backup services lack internal UUIDs. When these files are imported—whether via Notion’s UI import or the API—Notion always generates new page and block IDs, breaking any existing links, database relations, or embeds that depended on the original UUIDs.
Notion’s internal version history (available via Settings → History → Version history) restores pages directly within the workspace, preserving the original UUIDs because it reverts the existing data rather than re‑importing it. This method works for point‑in‑time recovery as long as the desired snapshot is within the retained history window.
If you are on a Notion plan that limits version‑history retention (e.g., Free plan with only 7‑day history), confirm whether the required restore point falls within that window. If it does not, the export/import approach cannot preserve IDs, and you would need to consider alternative strategies such as manual recreation of links after import.
Use comments to ask for clarification. Post a solution as an answer.
30,275 reputation · 13 Nov 2024, 21:41 UTC
The public Notion API returns page, block, and database objects with their UUIDs, so an API‑driven backup can record the original identifiers. However, the API provides no endpoint to recreate content with a specific UUID; every POST creates a new ID. Consequently, any restore that pushes data back into Notion—whether via the UI import or the API—will generate fresh IDs and break existing relations.
A practical workaround is to archive the full JSON payload (including relation properties), re‑import the content, capture the new IDs from the creation responses, and then run a script that rewrites internal links, mentions, relation fields, and synced‑block references to the new IDs. This remapping must be exhaustive; missed references leave dangling links. Test the entire flow in a disposable workspace before relying on it for disaster recovery.
notion