Context
AgenticOS wrote to Notion constantly, and the code that did it kept growing into something that was not really part of the harness. The honest test of whether an internal module is actually a library is whether it survives being pulled out.
notion-ops: published to PyPI
A Python operations library for Notion, carved out of AgenticOS and published as a standalone package with its own CI.
pip install notion-ops. Of everything on this page, it is the one claim you can check in ten seconds without asking me a question.
The problem
The Notion API is awkward in specific ways: it accepts at most two levels of block nesting per request, caps children at 100 per append, enforces payload ceilings, and returns transient 503s under ordinary load. Every consumer ends up reimplementing the same workarounds badly.
What I built
Pages, blocks, database and data-source operations. A markdown-to-Notion compiler that plans the minimum number of append requests for an arbitrarily nested document, splitting oversized tables and deferring deep sub-trees rather than silently dropping them. Retry discipline with exponential backoff for the 503s. Its own CI, and a public release on PyPI.
Results
In daily use across five repositories. Every Notion page produced by this practice, including the ones a client reads, goes through it.
What this shows about working with me
Maps to: The work
Turning internal tooling into something a stranger can install and use. The carve-out is the test: it forced real API boundaries, real error handling and real docs.