Reference
URLs, slugs and reserved names
Where a published dashboard lives, what a slug and a handle may be, how renames redirect, and which names are already taken.
The canonical URL
A dashboard lives on a subdomain, not on a path:
https://<workspace-slug>.dashies.ai/<slug>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:
https://<workspace-slug>.dashies.ai/<slug>/<filename>The old apex path form still works and redirects. A request to
https://dashies.ai/<first-segment>/<slug> 301s to
https://<first-segment>.dashies.ai/<slug>, 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 <slug>/<filename>. The workspace is added server-side from your
authorization, as the HOST; never include it in the path. A bare <slug> means
<slug>/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.
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'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.
mcp sso www api app assets auth admin
static cdn status docs mail ns1 ns2 datamcp 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:
pricing auth app assets apiauth, 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.
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://<workspace-slug>.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.