Common Error Messages

Search this page for the literal text you were shown. Every message here is reproduced exactly as Leed prints it, including the two with awkward grammar, because a reader pastes what they saw rather than what the sentence ought to say. The explanation lives in the next column; the string stays untouched so a search finds it.

How to read an error

Three status codes carry almost everything, and the difference between them is the difference between three completely different fixes.

• 403 is your role. The action exists, and you are not allowed to perform it. Nothing about your plan changes this; someone with a stronger role, or a resource override on that specific page or page type, has to do it or grant it to you. Privilege Matrix says which privilege each action needs.
• 402 is your plan. The action exists and your tier does not include it. This is the only class on this page a plan change resolves.
• 400, 404 and 409 are state. Something about the page, path, menu or deployment is not in a condition that allows the action — a path is taken, a page is unpublished, a version is stale, a deployment is not the newest one.

Leed keeps 402 strictly separate from 403 by design, so an upgrade prompt is never shown for a permissions problem and a permissions message is never shown for a billing one. If you are holding a status code, that split is the fastest way to know which page to read next.

In the page editor

Pages and page types

A page that will not publish for a missing summary is enforcing its page type’s required fields, which are set on Configuring a Page Type and enumerated with their per-kind defaults on Page Type Reference.

URLs, paths and menus

Publishing and deployments

Build error prefixes

Whether a failed build can be retried at all is decided by the prefix on its error message, not by anything you choose. [site-build] means the failure is in your content or templates and a Retry button is deliberately not offered; every other failure is infrastructure and is retryable.

Plans and quotas

Every entitlement denial in Leed — a feature gate, a quota meter, the analytics window — returns the same 402 body, so one shape covers all of them.

{
  "error": "upgrade_required",
  "reason": "feature_gated",
  "feature": "dynamicCta",
  "requiredTier": "growth",
  "currentTier": "free"
}

A quota denial carries the numbers instead of a required tier:

{
  "error": "upgrade_required",
  "reason": "quota_exceeded",
  "feature": "contacts",
  "currentTier": "free",
  "quota": 250,
  "used": 250
}

There is one case where a 400 pre-empts the 402, and it is the most misread status pairing in the product. A custom color theme, code theme or font name is shape-checked before the tier is consulted:

The stored value is the full prefixed class, so color-theme-leed is valid and color-theme-leed-ai is not — the leed-ai you supplied contains a dash. Because the shape check runs first, that name is a 400 on every plan, including Enterprise, never a 402 offering you an upgrade. Naming a custom theme at all is a Starter feature; the CSS behind the name is written in your repository — Custom Documentation Themes.

Signing in and account access

The remedies behind every one of these are on Sign-In Troubleshooting, and the workspace-membership 403s in particular are explained at Joining and Switching Workspaces.

Assets

MCP and AI clients

Three refusals can end a connection attempt, and all three arrive as a 403 whose body carries a reason.

Protocol-level failures come back as JSON-RPC error codes, each with a matching HTTP status:

A GET or DELETE against either MCP endpoint answers 405 with Allow: POST; both servers are POST-only. And a page write whose markdown uses a feature the page type disables is refused with a 400 that names both sides — This page type does not allow: alerts, tables. Allowed formatting features: code blocks. — which is explained at Formatting by Page Type.

Errors from the leed CLI

When you were shown nothing at all