Skip to main content
If your blog lives in a Notion database, Attensira can deliver articles into it and propose updates to posts that are already there.

​
Connecting

Connect Notion from the workspace’s integrations (Settings → Integrations) and grant access to the page that holds your blog database.
Choosing the blog database, and mapping its columns, has no screen in the app yet, and no MCP tool or API-key endpoint sets it. Until a database is chosen, an article sent to Notion is written and filed for your approval, but approving it writes nothing: it comes back to your Inbox saying no blog database is set up. Paste it into Notion yourself and mark it shipped with its live URL.
Once a database is chosen, the mapping says which property holds what: The mapping is checked against the database’s columns when it is saved, so a property that does not exist or has the wrong type is refused then, not at the first delivery.

​
How an article is delivered

When the agent writes an article that targets Notion, it waits in Work for your approval like every article does. Approving it (Send to Notion) creates a new row in the database, in its draft state.
  • Ask or draft mode: the row stays a draft for your team to publish in Notion.
  • Act mode: the row is set to published, and its published date to today, only if the mapping has a published value. Without one it stays a draft.
A post whose title already exists in the database is not duplicated. The item comes back to you with a link to the existing post.

​
How updates work

The agent can list and read the posts in your mapped blog, and propose an update to one as a before/after in your Inbox.
  • Updates always wait for your approval, in every mode, act included.
  • Approving replaces that post’s content in Notion. The old blocks are archived, not deleted, so Notion’s own history still has them. This is one of the two exceptions to the Connectors rule that nothing of yours is archived (the other is undoing a post we created), and it happens only on your yes.
  • An update never changes the post’s status.
  • We never delete a Notion post.
The agent tools behind this, list_blog_posts, read_blog_post and propose_blog_update, are offered only when a Notion blog database is mapped. See The agent’s tools.

​
After it ships

Publishing through Notion starts the before-and-after checks for the tracked prompts attached to the article, the same as a merged pull request.

​
Undo

A Notion change can be undone for 30 days after it was made, from the change itself or with POST /v1/changes/{id}/actions and "action": "undo".
  • A post we created is archived: off your blog, and in Notion’s trash, where you can restore it for 30 days. One already archived or deleted is left as it is.
  • An update is put back as it was. Before replacing a post’s content we keep its blocks, and the undo writes them back, formatting, links, code languages and ordinary nesting included. Some content cannot be brought back this way: files uploaded to Notion, embedded pages, blocks nested more deeply than one write can hold, and pages over 1 MB. When the undo cannot restore everything, it says what was left out, and Notion’s Page history has the exact earlier version with them. A property we changed gets its old text back.
  • Only while the post still reads as our update left it. If somebody edited it since, nothing is written: your Inbox shows the difference and points you to Page history, so you can bring back the earlier version and keep the edits you want.
Archiving the post is the only other time anything of yours is archived, and it happens only when a person asks for the undo. See Undo for how the CMS undo works.

​
Settings

The mapping is stored in project settings as notion_blog, with database_id, database_title, title_property, slug_property, status_property, status_kind, draft_value, published_value, body_property and published_date_property. Changes show in the settings log as notion blog: X → Y.