Notion closed a loophole your automation was living in, and the error blames your credentials

The error says to check your credentials

A workflow that has created Notion pages for a year stops creating them. The run fails. The message at the top of the failed node reads:

Forbidden - perhaps check your credentials?

So you check your credentials. You open the Notion integration settings, confirm the page is still shared with it, regenerate the secret, paste it back in, and run again. Same error. You start wondering whether somebody removed the integration's access, or whether the workspace got restructured, or whether a colleague revoked something.

None of that is it. Your token is fine, your permissions are fine, and nothing in your workspace changed. What changed is that on 1 September, Notion started enforcing a plan limit through its API that it had never enforced there before — and your workspace has been over that limit for a while without anything happening.

The real message exists. Notion sent it. It just did not reach your screen.

So what changed on 1 September?

The wording in the changelog is careful, and the third sentence is the one that matters:

Free workspace block limits now apply to the REST API. Starting today, the REST API enforces the existing Free workspace block limit for internal connections and OAuth connections restricted to selected workspaces. This is not a new workspace limit.

• Notion API changelog, 1 September 2026

Notion itself gives two dates for this. The changelog entry says "starting today" under 1 September; the reference page on request limits, read on 12 September, points to the same block limit as one "that takes effect on September 8, 2026". Whether enforcement began on the first or the eighth is not something the documentation settles, and for a workflow that was over the cap either way the difference is a week of grace, not a different outcome.

The limit itself is old. Free workspaces with more than one member have been capped at 1,000 blocks since at least 2024 — an archived copy of Notion's help page from November 2024 describes the same cap, the same lifetime counting and the same three-day grace period, in the help centre's own terms (it says "more than one workspace owner"; on a Free plan people can only join as owners, so it is the same set of workspaces). What was never true until September is that the API respected it.

So for as long as anyone can check, the way to have a Free Notion workspace with more than a thousand blocks in it was to put them there through an integration. Almost nobody did that deliberately. They set up a form-to-Notion automation, or a CRM built on a Notion database, and it wrote a few blocks a day into a workspace nobody thought of as constrained, because in practice it was not.

There was no warning in the changelog. The announcement is dated the day enforcement began and says "starting today", and no earlier entry mentions it.

Can you delete your way back under the limit?

This is the part that surprises people who understand the rest immediately, and it is worth being blunt about because it changes what the fix can be.

Free workspaces with more than one member have a limit of 1,000 lifetime blocks. Paid workspaces and single-member Free workspaces have unlimited blocks. Guests do not count as members. Deleting blocks does not restore capacity.

• Workspace block limits, Notion API reference

And from the help centre, answering the question directly:

Can I delete blocks to avoid these restrictions? No, deleting content does not reduce your block count or free up additional blocks. Once your workspace has created 1,000 blocks, it will experience restrictions — regardless of subsequent deletions.

• Understanding block usage, Notion help centre

The counter measures everything the workspace has ever created since sign-up. Emptying the trash does nothing. Archiving does nothing. A cleanup script does nothing except destroy your data while leaving the number where it was. There are two states available to a Free workspace, and "tidied up" is not one of them.

Which connections does this actually hit?

Read the scope carefully, because the intuitive guess — "all integrations" — is wrong, and Zapier, where nobody pastes a token in at all, is the one platform of the three that escapes it entirely:

The limit applies to internal connections and OAuth connections restricted to selected workspaces. It does not apply to personal access tokens or OAuth connections that can be installed in any workspace. Notion MCP has a separate enforcement policy.

• Workspace block limits, Notion API reference

Translated into the three platforms:

Notion names none of these platforms; the column is what follows from applying its scope to each one's documented connection type. On n8n Cloud, whether a managed public OAuth connection exists is not documented either way — check the credential you actually use.

The pattern underneath is unflattering to the people who did the more technical thing. Creating your own integration in Notion's developer settings and pasting the secret into your automation is the more deliberate, more self-reliant setup. It is also the one now subject to the limit, while the click-through OAuth connection that asks you nothing is not.

For n8n specifically this is close to automatic. The internal secret is the default and the path of least resistance — the API-key credential's only field, and the one every tutorial starts with. Self-hosted users who set up their own OAuth application instead are also caught if they scoped it to selected workspaces, which is the natural choice when you are configuring it for your own company.

Notion wrote a good error. Here is what you see instead

The response body Notion documents for this situation is close to ideal:

{
  "object": "error",
  "status": 403,
  "code": "restricted_resource",
  "message": "This workspace has used all of its free blocks. Upgrade its plan in Notion to create more content. Learn more: https://www.notion.com/help/understanding-block-usage",
  "additional_data": { "block_limit": "block_creation" }
}

It names the cause, names the fix, links to the explanation, and includes a machine-readable field so code can distinguish this from an ordinary permission failure without parsing English. Notion even says why that field exists: "Other permission failures also use restricted_resource. The additional_data.block_limit field identifies this limit without relying on message text."

Now the n8n side. The Notion node wraps any HTTP failure in the platform's standard API error object. That object carries a table of replacement headlines by status code, and the entry for this one reads:

'403': 'Forbidden - perhaps check your credentials?',

When the code matches, the original message is pushed into the error's details and the headline is replaced with that string. So Notion's sentence about free blocks survives — it is moved into the error object's list of messages — while the headline the platform substitutes is a guess about credentials that happens to be wrong. That is what the error object does; exactly how a given version of the editor renders those details on screen is another matter.

This is not a Notion-specific bug, which is rather the point. It is a generic mapping that turns every 403 from every service into the same sentence, and it is right often enough that nobody has questioned it. The cost only appears when a vendor takes the trouble to explain itself and the explanation gets demoted.

Make behaves differently and better here through no particular virtue — it just passes the vendor's text through, in the form The operation failed with an error. [403] followed by whatever the service said, which is the shape its forum shows for 403s from other vendors. On that pattern, a Make user hitting this would read Notion's sentence. An n8n user reads a hypothesis about credentials.

If you have ever chased a credential that looked expired and was not, this is the same trap from the opposite direction: there, the platform failed to act on an error it should have recognised; here, it overwrites one it should have shown you.

What stops, and what carries on?

Once the grace period is spent, the split is clean: anything that creates a block fails, anything that does not keeps working. Notion's own table, condensed:

Reads, deletes and edits that do not create blocks are unaffected.

That asymmetry produces a specific kind of half-broken automation, and it is worth picturing before it happens to you. A workflow that updates a status property on an existing page carries on perfectly. A workflow that files a new record stops. A workflow that does both, in sequence, does the first half and fails the second — so the dashboard updates and the record it refers to never gets created.

There is also a failure that does not look like one at all:

A successful create or update response does not guarantee that a queued template will finish. The job checks the limit again before copying content and before each content write. If the workspace becomes blocked, the job stops without retrying […] The target page is kept, but it may be blank or contain only part of the template.

• Workspace block limits, Notion API reference

You get a 200. The page exists. It is empty, or half filled. And Notion is explicit that there is "no template-failure webhook or public job-status endpoint" — the only way to know is to read the page's children back afterwards and count. They also warn, sensibly, not to automatically reapply the template to a partially populated page, because that duplicates content.

The grace period you have probably already used

Notion offers three days after the write that first crosses the line. That write succeeds; creation keeps working while the clock runs.

But this is the workspace's existing grace period, not a fresh one for the API:

API enforcement does not restart an expired grace period.

• Workspace block limits, Notion API reference

Which means the workspaces that hit this hardest are the ones that crossed a thousand blocks in the browser months or years ago, saw the banner, ignored it because the integration kept working anyway, and let the three days lapse. For them there was no grace on 1 September. There was a 403 on the first write of the day.

And retrying is not a strategy: "This is a plan limit, not a request rate limit. Retrying the same write without a workspace change will not resolve it." Any node with retry-on-fail enabled will simply hammer the wall on a schedule.

How much is a thousand blocks?

Notion's counting rule is broad — "Every piece of content you add is counted as a new block" — and the API documentation lets you derive the arithmetic that matters for automations, though Notion does not publish it as a formula.

From the endpoint table: a page is one block, and each appended child is another. So a workflow that creates a page with ten paragraphs of body writes eleven blocks. Run that on every inbound form submission and a thousand lifetime blocks is about ninety submissions. Not ninety a month — ninety, total, for the life of the workspace, plus everything anyone typed by hand.

Two things Notion does not publish, so do not let anyone estimate around them: how many blocks a database row with several properties consumes, and whether properties count separately. Teamspaces, at least, are confirmed not to count.

The ways out, from most honest to least

Upgrade the workspace. Plus is $12 per member per month billed monthly, or $120 per member per year. For a two-person Free workspace running a business process through the API, this is the answer, and everything below is a way of avoiding a bill that is smaller than one hour of anybody's time. A workspace owner has to do it; the automation cannot.

Make the workspace single-member. Notion suggests this itself: remove the other members so only one remains, and blocks become unlimited. Collaborators can be re-added as guests, who do not count as members, "in a more limited capacity". Whether that is a real option depends entirely on what those people do all day.

Move the storage somewhere else. If Notion is being used as a database rather than as a place people read, the lifetime counter is a structural argument against keeping the data there on a Free plan — you cannot ever clean up and continue. This is the same question as using a spreadsheet as a database: the tool is fine, the role it has been given is the problem.

Change the token type. By the letter of the scope, a personal access token or a public OAuth connection installable in any workspace is not subject to the limit. This is not something Notion recommends, and it should not be read as advice — it is a gap in how the rule is drawn, and a gap that clearly runs against the intent of the change is not a thing to build a business process on. A personal access token also inherits one person's access and dies when they leave, which is its own failure waiting to happen.

Not an option: deleting content, retrying, or waiting.

Working out whether this is coming for you

Most of the diagnosis is a plan-and-count exercise rather than anything technical, and it takes about ten minutes.

1. Check the workspace plan and the member count. Free with two or more members is the only combination affected. Free with one member is unlimited, and any paid plan is unlimited.
2. Check how Notion is connected in each automation. In n8n, an "Internal Integration Secret" in the credential means you are in scope. In Make, look at whether the connection is the internal or the public one. In Zapier, the documented setup has no token field at all, which by the letter of the scope puts it outside the limit.
3. Look for the real message, not the headline. In n8n, open the failed node's error details — Notion's sentence about free blocks is in the error object, not in the headline. Better, if you are handling errors in code, key on additional_data.block_limit rather than on the message text, which is what that field is for.
4. Expect this one workspace at a time, not all at once. Workspaces cross a lifetime threshold on their own schedule, so it arrives as a trickle rather than an outage — which is why nobody had posted about it in the first week, and why that means nothing in either direction.
5. Check your template-driven pages actually have content in them. If any workflow creates a page from a template, the successful response does not prove the page was filled. Read the children back if it matters.
6. Turn off retry-on-fail for Notion create steps while you sort the plan out. It cannot succeed, and all it does is bury the real error under repeated identical ones.

When this is a job to hand over

The 403 forces a question nobody was planning to answer this quarter, and it is not "how do we get creation working again". It is: should this data have been in a Notion database at all?

A workspace that is a place people read and write in is worth the subscription without argument, and the upgrade is the end of the matter. A workspace that is really a table your automations append to, which humans open twice a month, is paying a per-seat collaboration price for storage — and it will keep meeting limits shaped like this one, because it is being used as something it is not. The lifetime counter is what makes that distinction permanent rather than a matter of tidying up.

That is a decision about where things live, and the work that follows it can be counted before it is quoted: how many workflows write to Notion, how many fields each one maps, what reads from it downstream. It is a move rather than a repair, and we price moves the same way we price fixes — taking one thing out of a tool that was never meant to hold it.

The detail to carry away from all this has nothing to do with Notion's pricing. A vendor wrote the clearest error message in this entire article — cause, consequence, fix, link, and a machine-readable flag so you would not have to parse the English — and by the time it reached the person who needed it, it had been replaced with a guess about credentials. Before you trust what your automation platform tells you went wrong, it is worth finding out what the service actually said.

Sources

• Notion API changelog - read 8 September 2026. The 1 September entry announcing that Free workspace block limits now apply to the REST API, its scope, and the statement that this is not a new workspace limit. No earlier entry mentions the change.
• Workspace block limits - Notion API reference, read 8 September 2026. The 1,000 lifetime block limit for Free workspaces with more than one member, unlimited blocks for paid and single-member workspaces, guests not counting as members, deletion not restoring capacity, the connection types in and out of scope, the three-day grace period and the note that API enforcement does not restart an expired one, the full 403 response body with its additional_data.block_limit field, the endpoint-by-endpoint table of what fails and what still works, and the background template behaviour including the absence of any failure webhook or job-status endpoint.
• Understanding block usage - Notion help centre, read 8 September 2026. The lifetime counting rule, the explicit answer that deleting content does not reduce the count, the suggestion to reduce the workspace to a single member and re-add collaborators as guests, and the statement that every piece of content added counts as a block.
• Understanding block usage, archived November 2024 - read 8 September 2026. Establishes that the 1,000-block cap, the lifetime counting and the three-day grace period all predate the API change by nearly two years.
• Request limits - Notion API reference, read 12 September 2026. The cross-reference to the Free workspace block limit "that takes effect on September 8, 2026", a week later than the changelog's date.
• Status codes - Notion API reference, read 8 September 2026 from the raw HTML to confirm the description belongs to the restricted_resource row rather than a neighbouring one.
• Notion pricing - read 8 September 2026 from the pricing data embedded in the page. Plus at $12 per member per month billed monthly and $120 per member per year; Business at $24 and $240 respectively.
• n8n source, the Notion node and the API error class - read 8 September 2026 from the raw files on master. Both the version 2 and version 3 transport layers wrap HTTP failures in the platform's API error object, and that object replaces the headline for a 403 with "Forbidden - perhaps check your credentials?" while moving the original message into the error's details. The credential's single field is the Internal Integration Secret. How the editor renders the demoted message underneath the headline was not verified in a running instance.
• Notion app documentation - Make, read 8 September 2026. The two documented connection types, internal and public, and which field each one asks for.
• How to get started with Notion on Zapier - Zapier Help Center, updated July 2026, read 8 September 2026 through the help centre API. Authentication is OAuth through Zapier's own application with no token field, which places it outside the scope of the limit.
• community.n8n.io and community.make.com - searched 8 September 2026 for the error code, the message text and the block limit. No reports on either forum in the first week of enforcement, and none in the n8n or Notion issue trackers on GitHub.
• New API key won't work - n8n community, September 2023, read 8 September 2026. An unrelated case, three years before this change, of the same substituted headline sending someone to reissue a working token.
• Personal access tokens - Notion documentation, read 8 September 2026. What a personal access token is and whose access it carries.