--- 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-27 --- ## The canonical URL A dashboard lives on a subdomain, not on a path: ```text https://.dashies.ai/ ``` 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.ai// ``` **The old apex path form still works and redirects.** A request to `https://dashies.ai//` 301s to `https://.dashies.ai/`, preserving the filename and the query string. The rewrite is a string substitution over whatever the first segment is, so a workspace slug redirects exactly as an old handle did. It fires without any lookup, so it is byte-identical for a dashboard that exists and one that does not: it reveals nothing you did not already type. ## What you pass, and what is added for you You pass `/`. **The workspace is added server-side** from your authorization, as the HOST; never include it in the path. 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.ai`, 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 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. Every path that mints a slug refuses these five: publishing a **spec**, publishing a **body**, and **renaming** onto one. The refusal names the URL that would have been shadowed, so you can see which dashboard you were about to hide. Renaming a dashboard **away from** a reserved slug is allowed, which is how a dashboard that predates the guard gets off one. :::note{title="This used to have two gaps, and they are closed"} Until the personal space was retired, only the spec publish carried this guard. The legacy body publish and the rename did not, so a dashboard slugged `pricing` published cleanly on those paths and then **redirected to the apex pricing page** rather than serving the dashboard. If you have a dashboard on one of these five slugs it was minted through one of those paths; rename it, which is permitted. ::: `privacy` and `terms` are apex-only pages and are **deliberately not reserved**, so `https://.dashies.ai/privacy` resolves as a dashboard slug like any other. ## Who can open the URL There is no visibility setting. **Current members of the workspace the dashboard lives in, and nobody else.** **Nothing is viewable anonymously.** A signed-out request is redirected to sign in, carrying the URL as the return path, so the visitor lands on the dashboard after signing in if their account may see it. None of this is plan-gated, and there is no publish quota. A dashboard a signed-in person may not 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. A signed-OUT request is answered by the sign-in redirect before anything is looked up, so it too is identical either way. ## Check it worked Open the canonical URL in a private browser window. You should get the sign-in page with the dashboard's URL carried through - **that is correct, not a broken link.** Sign in and you land on the dashboard. If you renamed it, load the **old** URL too and confirm it lands on the new one.