Cloudflare’s own guide for adding many sites by script ends with two limits. The page was last updated on 5 May 2026 and it says:

There are limitations on the number of domains you can add at a time - specifically, you can only sign up a maximum of 25 domains every 10 minutes.

In addition, if you have over 50 domains and, of those domains, more are pending than active, you will be blocked from adding more. We recommend waiting until your pending sites have been activated before adding more.

The portfolio runbook on this site reads the second one the way it is written: a ratio with a threshold. Under fifty domains there is nothing to plan around. That is also what we believed when 301.st started adding zones for the accounts it onboards, with a scoped API token, the credential Cloudflare tells you to use. This is what came back:

{
  "success": false,
  "errors": [
    {
      "code": 1118,
      "message": "You have exceeded the limit for adding zones. Please activate some zones."
    }
  ],
  "messages": [],
  "result": null
}

It came back on accounts with a handful of domains. On a fresh account it came back on the second one.

The rule that fits the evidence

The error is old and the community has been reporting it since before the guide had a number in it.

  • March 2019. A Cloudflare staff member closes a thread about code 1118: there is a limit on the number of pending zones at any one time, and validating pending zones is what raises it. No threshold is named.
  • September 2021. A poster quotes the support article of the day, which had no threshold either: you cannot have more pending sites than active sites on the account.
  • December 2024. Ten zones, three active, seven pending, blocked. The poster had read that the limit was fifty and asks why theirs is ten.
  • January 2025. A Free account with one zone. Adding the second returns 1118. The poster deletes everything and tries again: with no zones, one goes in; the next does not.

One rule fits every case, and it is the rule we see on the accounts we onboard: a new zone is refused once the account has more pending zones than active ones. The fifty domain threshold from the guide did not show up in any of them. Put plainly, you can add about as many zones as you already have active, and a new account with nothing active gets one.

That alone changes the plan for a portfolio. It is not add fifty, activate, add fifty. It is add one, activate it, add two, activate them, add four. The ceiling doubles with each round and the first rounds are the slow ones, because activation waits on a nameserver change at the registrar and on Cloudflare noticing it.

The part that depends on who is asking

Here is the piece we have not found written down anywhere.

The same account, the same list of domains, the same request to the same endpoint. With an API token, scoped as Cloudflare recommends, the block lands as soon as pending outnumbers active. With the user’s Global API Key, the batch goes in. The only limits we have run into with the key are the two documented ones: 25 domains per 10 minutes, and the ratio once the account is past fifty.

Request signed with A new zone is refused when Source
API token, user or account owned pending zones outnumber active ones, from the second domain on a fresh account observed on the accounts we onboard, matches every thread above
Global API Key over 50 domains on the account and pending outnumber active the guide, and what we see with the key
Either more than 25 domains in 10 minutes the guide

Our reading is that the key acts as the user, the same principal as the dashboard, while a token is automation, and the pending cap applied to automation is the stricter one. That is a reading, not a statement from Cloudflare. Treat the whole section as observed behaviour on accounts we run, and check it on yours before you build on it.

Check your account in two requests

Count what you have. The zones endpoint filters on status and reports the total without paging through the list:

for s in active pending; do
  printf '%s: ' "$s"
  curl -s "https://api.cloudflare.com/client/v4/zones?account.id=$ACCOUNT_ID&status=$s&per_page=1" \
    -H "Authorization: Bearer $CF_API_TOKEN" | jq '.result_info.total_count'
done

If pending is already at or above active, try adding one domain you own with the token:

curl -s -X POST "https://api.cloudflare.com/client/v4/zones" \
  -H "Authorization: Bearer $CF_API_TOKEN" \
  -H "Content-Type: application/json" \
  --data "{\"name\":\"$DOMAIN\",\"account\":{\"id\":\"$ACCOUNT_ID\"},\"type\":\"full\"}" \
  | jq '.success, .errors'

A false followed by code 1118 means your account is under the rule above, not under the one in the guide. We have not found a plan that lifts it; the staff answer from 2019 names activation as the only lever. From here there are three ways forward.

  1. Activate what is pending. Change the nameservers at the registrar, wait for the zone to go active, and the ceiling rises by one. This is the right answer and the slow one: hours per round, sometimes a day.
  2. Add through the dashboard by hand. One at a time, which is the work you were scripting away.
  3. Use the Global API Key for the adding step. Which raises the question of where that key is allowed to live.

Why the key must not leave your browser

Cloudflare’s page on the Global API Key lists what is wrong with it:

Access to all Cloudflare resources - Global API key has access to all of a user’s resources. This makes it impossible to safely use Global API key to access non-production resources when a user also has access to production resources.

Full permissions - Similarly, Global API key has the exact same permissions as the user, which means if the user can delete zones or change DNS records, so can the Global API key.

For these reasons, Global API key is not recommended for new customers. Current customers using Global API key are encouraged to migrate and use API tokens instead.

A platform that stores your key holds everything you hold. 301.st does not store it: onboarding takes a scoped token, and the quick path that accepts a key uses it once to mint a scoped token and discards it. That is the right design, and it means the server side of 301.st cannot perform the one step where the key is what gets through.

So the adding step moved to the one place where the key can stay yours: your browser. Cloudflare Tools is an extension we wrote in January 2026 for exactly this, and it is open source. You paste the key into the side panel. It is encrypted with AES-256-GCM under a random key that lives in session storage and is gone when the browser closes. Every request goes from your browser to api.cloudflare.com and nowhere else; no server of ours is in the path. Paste a domain list, run a preflight that sorts it into will create, exists, invalid and duplicate, and start. The batch runs at Cloudflare’s pace, 25 per 10 minutes, backs off on a 429 with Retry-After, and resumes after a browser restart. The same panel does check and export to CSV, bulk delete and bulk cache purge.

It is our tool, not Cloudflare’s, and it is not affiliated with or endorsed by Cloudflare.

What changed in 0.2.0

Version 0.2.0 shipped on 1 September 2026. It is live on Firefox Add-ons and going through review on the Chrome Web Store and Edge Add-ons, so those two links carry the previous version until it clears.

  • Tokens, not only the key. User tokens (cfut_) and account owned tokens (cfat_) are accepted alongside the Global API Key, and the kind is detected from the pasted secret. When your account already has active zones to spend, a token with Zone, Zone, Edit on the account is enough and the key never has to be pasted anywhere. Add Cache Purge if you purge.
  • Profiles. Several accounts or credentials, switched from the header. A running batch stays on the profile it started under, whatever you switch to meanwhile.
  • The toolbar button opens the panel directly, the UI follows the browser language in English and Russian, and the publisher news feed is opt in and off by default.

The next release, 0.3.0, closes the loop on the limit itself: when one account’s pending count hits its ceiling, the rest of the list spills to the next profile. The limit is per account, so a portfolio spread over several accounts is the ceiling multiplied.

Where the extension stops

It adds zones. It does not move them from pending to active, because that happens at the registrar, and it does not tell you next month which of them are still pending, which record went grey, or which domain was supposed to point where. Its job ends when the batch is in.

Keeping the portfolio true after that is what 301.st does, and the runbook lists the steps it takes over. For the batch in front of you today, install the extension and paste the list.