The Notion API rate limit caps how many requests one form connection can send. On most workspace plans it is 180 requests per minute, and on Business and Enterprise it is 600. For a form, each submission usually costs at least one request, so a sudden burst can push some writes over the limit, and Notion answers those with an HTTP 429 error instead of creating the row.
Whether you lose the response depends on what your form tool does next. If it waits and retries, the row lands a little late. If it sends each response once, the row can be gone.
How the Notion API rate limit works
The Notion API rate limit is two limits: one per connection and one per workspace. According to Notion’s request limits documentation, each connection gets a fixed budget per 60-second window, based on the workspace plan:
| Workspace plan | Per-connection limit |
|---|---|
| Business and Enterprise | 600 requests per minute (an average of 10 per second) |
| All other plans | 180 requests per minute (an average of 3 per second) |
You can spend the budget at any pace within the window, evenly or in one burst. Querying a data source has its own separate limit of about 3 requests per second per connection.
The second limit is the per-workspace limit, shared by every connection in your workspace. People miss this one. Your form tool can sit well under its own budget and still get a 429 because a sync tool, an automation and a dashboard are all hitting the same workspace.
What a burst of form submissions looks like
A burst of form submissions is the normal way a form reaches the limit: a newsletter goes out, a launch post lands, or a class of students opens the same assignment link at 9:00. Every submission becomes a request to create a page, and some tools spend extra requests reading the database schema or attaching files.
Say you run a workshop registration form on a Free or Plus workspace, and you also have an automation that updates a “Seats left” counter on every new row. Each sign-up now costs at least two requests in the same window. Past the limit, Notion returns:
- HTTP status 429
- error code
rate_limited - a
Retry-Afterheader, an integer number of seconds to wait
For the per-connection limit, Retry-After is the time until the window resets, so it is at most 60 seconds. For the shared workspace limit it can be longer than a minute.
Which limit stopped your form?
Notion tells you which limit fired in the additional_data.rate_limit_reason field of the error. The ones a form is most likely to hit:
public_api_request_rate_limit: this connection is sending too fast. Wait forRetry-After.public_api_space_request_rate_limit: the whole workspace’s shared budget is used up. Wait, and look at what else is calling the API.public_api_endpoint_rate_limit: one endpoint has its own limit.public_api_request_blocked: the connection’s API access has been restricted. Retrying won’t help; Notion says to contact support.
No access to raw error logs? Open the connection’s Health tab in Notion. It lists the rate limits that connection reached in the last 24 hours, which is the quickest way to tell a rate-limit problem from a form that has stopped syncing to Notion for a permission or property reason.
How a form tool should handle 429 errors
A form tool should never treat a 429 as a failed submission. Notion’s guidance: queue outgoing requests, pause for at least the Retry-After time, retry, and use exponential backoff with jitter if another 429 or 529 arrives. Set a retry limit and log the final error so nothing fails silently. A 529 service_overload means Notion itself is temporarily overloaded; treat it like a 429.
Tools built on Notion’s official JavaScript client get some of this for free. The notion-sdk-js README says the client retries failed requests up to 2 times by default, retries rate_limited and service_overload for all methods, and uses Retry-After when present. Two retries cover a short spike. For a longer outage you need a stored copy of the response.
Why retries can create duplicate rows
Retrying a write is not always safe. Notion’s documentation says a write can save its change and still return a 503, because Notion ran out of time building the response. Repeating that write applies the change twice, which for a form means two identical rows in your database.
That is why the official client only retries 500 and 503 errors for GET and DELETE requests, never for page creation. Notion’s advice is to read additional_data.retry_guidance before retrying a write; when the change was already saved, the guidance says to read the object instead.
Seeing the odd duplicate? Check the timestamps. Two identical rows a few seconds apart usually mean a retried write, not a person submitting twice.
Size limits that look like rate limits
Some rejected submissions have nothing to do with speed. Notion also caps the size of each request, and breaking a cap returns HTTP 400 validation_error, not 429. The caps that matter for forms:
- a rich text
text.contentvalue: 2000 characters - any URL: 2000 characters
- an email or phone number: 200 characters
- a multi-select: 100 options; a relation: 100 related pages
- the whole payload: 1000 block elements and 500KB
Long-answer questions are the usual culprit. Someone pastes in a full cover letter and it can exceed the 2000-character rich text limit unless the tool splits it. If you’re mapping form fields to Notion properties, map long answers to a text property and test with a long sample before launch. File questions work differently; see how file uploads reach a Notion form.
How nDBForms handles rate-limited writes
nDBForms writes every response to your Notion database through the official Notion API client, and it also keeps a copy of each response in its own database (Cloudflare D1). The dashboard shows that copy, and nDBForms uses it for retrying failed Notion writes, as its security page describes. A response that hits a 429 waits instead of disappearing.
The limitation: a stored copy does not make Notion faster. If other tools have used up your workspace’s shared budget, rows arrive late until the window resets. A response rejected for a size or permission reason keeps failing until you fix the database, so check the submissions that are not showing in Notion and the cause behind them.
Do you need to worry about the limit?
Most form owners never see the Notion API rate limit at all. A form that collects a few dozen responses a day is far below 180 requests per minute, even with a couple of automations running on the same workspace.
My take: the limit is a real risk in three situations, and you should plan for them before launch day, not after.
- Launch-day bursts: hundreds of people submit in the same minute.
- Busy workspaces, with several connections drawing on one workspace budget.
- A tool with no stored copy. A failed write is simply gone.
If any of those fit, pick a tool that keeps responses and retries them, and keep extra automations off the target database during the busiest hour. Read the general the general limitations of Notion forms too.
FAQ
How many requests per second does the Notion API allow?
On most plans a connection gets 180 requests per minute, an average of 3 per second. Business and Enterprise workspaces get 600 requests per minute, an average of 10 per second.
What happens to a form response that hits the Notion rate limit?
Notion rejects the write with HTTP 429 and a rate_limited code. The response only reaches your database if the form tool waits for the Retry-After time and sends it again.
Can I see when my connection was rate limited?
Yes. The connection’s Health tab in Notion lists the rate limits it reached in the last 24 hours.
Why do I sometimes get duplicate rows after a failed submission?
A write can be saved and still return a 503 error. If the tool repeats that write, Notion creates the page twice, which is why Notion says to read the retry guidance before retrying.