Notion Release Notes

Two months ago, we launched Custom Agents in beta. Since then, teams have created more than half a million of them and honestly pushed them further than we expected!

One theme from admins was consistent: as Custom Agents scaled, so did the need for more control and visibility. Your feedback shaped what we built next, so here’s what's new.

Set guardrails before Custom Agents run

Managing who can create Custom Agents and how much each agent is allowed to spend make rollouts easier to manage:

• Start by choosing who create agents, either individuals or user groups, then expand access over time as you build confidence. You can do this in Settings → Notion AI → Agents.
• To keep spend predictable, set per-agent credit limits with agent creators. If you’re on Enterprise and planning a broader rollout, you can also set one workspace-level credit limit that applies to all new and existing agents. Both controls are in your usage dashboard at Settings → Notion credits.

Track every agent and spend across your workspace

The Notion credits dashboard shows total usage broken down by agent, plus spend trends, status, and recent activity.

If an agent is pacing higher than expected, you can disable it right away in Settings → Notion AI → Agents, then work with the creator to adjust it before turning it back on.

If you manage multiple workspaces, you’ll also see a credits dashboard in your admin console to track credit pacing and Custom Agent usage across your organization.

Scale agents with built-in guardrails

A few things happen automatically to keep rollouts predictable even at scale:

• Get notified by email and in-app as your workspace approaches its credit limit, so you’ve time to plan ahead.
• If credits run out, all agents pause until you add more, so you won’t get surprise bills.
• If a new agent starts spending unusually fast, we’ll pause it and notify the creator to review.
• Members can request a higher credit limit, but nothing goes through without admin approval.

Improvements to pagination reliability for the Query a data source endpoint

• Pagination cursors now embed a session identifier, eliminating intermittent 400 validation_error (“The start_cursor provided is invalid”) errors that could occur when multiple pagination sessions for the same query overlapped.
• The start_cursor parameter now accepts opaque string values in addition to UUIDs. Existing UUID-based cursors continue to work. As documented in our versioning policy, cursors should always be treated as opaque — pass next_cursor values back as start_cursor without parsing or validating their format.

Data source and view query pagination limit

The Query a data source, Create a view query, and Get view query results endpoints now enforce a maximum pagination depth of 10,000 results per query. When a query matches more rows than this limit, the response includes a new request_status field:

{
  "request_status": {
    "type": "incomplete",
    "incomplete_reason": "query_result_limit_reached"
  }
}

Integrations that polled these endpoints to iterate through all matching rows in a large data source should check for request_status.type === "incomplete" and adapt accordingly. The limit improves reliability for all API users by bounding the server-side resources consumed by each query.

If your integration needs to process all pages in a large data source, we recommend:

• Using data source filters or narrowing the view’s filter/sort configuration to reduce the result set (for example, filter by last_edited_time to only fetch recently changed pages).
• Setting up integration webhooks for incremental sync instead of polling the full data source on a schedule.
• Dividing large data sources into multiple smaller ones.

SDK support: @notionhq/client v5.20.0 adds typed support for the request_status field on affected list responses.

Update and delete comment endpoints

The Update a comment ( PATCH /v1/comments/:comment_id ) and Delete a comment ( DELETE /v1/comments/:comment_id ) endpoints are now generally available. Non-DLP integrations can only modify or delete comments they created.

Multi-value filters for select, status, and multi_select properties

Database and data source filters now accept an array of values for equals / does_not_equal on select and status properties, and for contains / does_not_contain on multi_select properties, matching the multi-value conditions available in the Notion UI. The same schema is used by view filters and quick filters. Person filters set via the API also now round-trip cleanly on read without extra combinator nesting.

Notion MCP improvements

The search tool no longer drops Slack DMs and private channel results when the connected workspace has the Slack integration enabled.

The fetch tool now accepts any first-party Notion domain for the current environment (both notion.so and notion.com), fixing cases where pasted links fell through as generic webpages.

Page resources returned by the fetch tool now include is_archived so agents can tell when a page is in the trash.

The enhanced Markdown guidance the MCP presents to LLMs now documents
as the correct way to break lines inside inline code, preventing retry loops when agents write multi-line inline code via update_page.

The Notion MCP OAuth server adds Client ID Metadata Document (CIMD) support per MCP spec 2025-11-25, letting clients use an HTTPS URL as their client_id instead of going through Dynamic Client Registration.

Comment markdown formatting clarification

The Create a comment and Update a comment references now explicitly document that the markdown body parameter supports inline formatting only — fenced code blocks, headings, lists, tables, and blockquotes do not render as structured blocks in comments.

SDK support : @notionhq/client v5.18.0 adds typed support for multi-value select, status, and multi_select filters. v5.19.0 adds notion.comments.update() and notion.comments.delete().