--- title: URLs, slugs and reserved names description: Where a published dashboard lives, what a slug and a handle may be, how renames redirect, and which names are already taken. updated: 2026-08-05 --- ## The canonical URL A dashboard lives on a subdomain, not on a path: ```text https://.dashies.xyz/ https://.dashies.xyz/ ``` Every success message the server emits uses that form, and it is the form to share. A dashboard published with several files serves the rest beneath it: ```text https://.dashies.xyz// ``` **The old apex path form still works and redirects.** A request to `https://dashies.xyz//` 301s to the subdomain, preserving the filename and the query string. That redirect fires without any lookup, so it is byte-identical for a dashboard that is public, private or absent: it reveals nothing you did not already type. ## What you pass, and what is added for you You pass `/`. **The handle is added server-side** from your authorization; never include it. A bare `` means `/index.html`. | Rule | Value | |---|---| | Slug characters | `^[a-z0-9-]+$` | | Slug length | 64 characters | | Filename characters | `^[a-z0-9._-]+$` | | Path shape | exactly one or two segments | The full refusal texts are in [Shared rules](/reference/mcp-tools/conventions#paths-and-slugs). A spec's optional `slug` field is **stricter** than the path rule: it must match `^[a-z0-9](?:[a-z0-9-]{0,62}[a-z0-9])?$`, so it cannot start or end with a hyphen. It must also equal the publish path's slug; renaming is [`update_dashboard`](/reference/mcp-tools/update-dashboard)'s job, not the spec's. ## Uniqueness **Slugs are unique per account**, and per workspace. Two people may each own a dashboard called `sales`; so may two workspaces. What cannot repeat is one slug twice inside one account or one workspace. **Aliases share that namespace.** A rename leaves the old slug behind as a permanent alias that 301s to the new canonical URL, and that alias occupies the name: you cannot rename a second dashboard onto a slug an earlier rename left behind. ## Handles and workspace slugs share one namespace Your handle and every workspace slug are labels under `dashies.xyz`, and they are registered in **one shared unique namespace**. A handle can therefore never equal a workspace slug, and the collision is refused atomically when the second one is created rather than discovered later at a URL. Your handle is generated at sign-up from your email. It is capped so the final label fits a 63-octet DNS label, and where the derived name would collide with a reserved label or an existing one, a suffix is added. ## Reserved subdomain labels Sixteen labels can never be a handle or a workspace slug. They belong to infrastructure or to conventional service names, and a request reaching one is refused before any dashboard lookup. ```text mcp sso www api app assets auth admin static cdn status docs mail ns1 ns2 data ``` `mcp` is the publish server, `sso` the SAML service, `docs` this site, and `data` the cross-origin query engine host. The rest are held so they cannot be taken. ## Reserved first path segments Five words are routes of the Dashies web app itself. On a subdomain those routes would shadow a dashboard of the same name, so they are **also refused as a personal dashboard slug**: ```text pricing auth app assets api ``` `auth`, `app`, `assets` and `api` are in both lists. `pricing` is the only one of the five that is **not** also a reserved subdomain label, so it is refused as a slug while remaining available as a workspace slug or a handle. The two lists are not near-identical in the other direction: twelve of the sixteen subdomain labels do not appear here at all. :::warning{title="One legacy publish path does not enforce this"} Publishing a **spec** is refused on both scopes: the guard runs after the scope is resolved, and the refusal names the workspace URL when that is where you were publishing. Renaming onto one of these is refused too. Since the spec is the supported authoring path, that is what you will hit. The gap is the **legacy body publish into a workspace**, which carries no such guard. There, a workspace dashboard slugged `pricing` publishes cleanly and its URL then **redirects to the apex pricing page** rather than serving the dashboard, because those routes are apex-only and a subdomain sends them there. Avoid all five in a workspace as well; on that one path nothing stops you. ::: `privacy` and `terms` are apex-only pages and are **deliberately not reserved**, so `https://.dashies.xyz/privacy` resolves as a dashboard slug like any other. ## Visibility | Visibility | Who can open the URL | |---|---| | `public` | Anyone with the link. No sign-in. | | `private` | You. A signed-out request is sent to sign in. | | Workspace `private` | Current members of that workspace. | A new personal dashboard defaults to `public`; a new workspace dashboard defaults to `private`, which is members-only. Visibility is **not** plan-gated in either direction, and there is no publish quota. A dashboard a non-member cannot see returns the same 404 as one that does not exist. That is deliberate: a distinguishable "exists but is not yours" would make the URL an existence oracle. ## Check it worked Open the canonical URL in a private browser window. A `public` dashboard renders; a `private` one bounces you to sign in. If you renamed it, load the **old** URL too and confirm it lands on the new one.