Can clients approve a design without creating an account?
How tokenized client approval links work, why the whole category moved away from client accounts, and the three safeguards — scope, revocation and expiry — that make a no-login link safe to send.
By Idan Mann, founder of NYA
The short answer
Yes. A client approval link works by putting a secret token in the URL, so opening the link is the authentication and no account is ever created. Programa, Planify and NYA all publish links that work this way. The safeguards that matter are per-link scopes, the ability to revoke a link, and an expiry date.
Client accounts were the default in this category for a decade, and they quietly cost designers a great deal of work. Every project began with a password reset. Every approval was gated behind a step the client had no reason to want. The industry has largely abandoned the pattern, and it is worth understanding what replaced it before you evaluate tools on it.
How a no-login approval link works
The link you send contains a long random token — a string nobody can guess and nothing links to. Loading that URL is what proves the holder is allowed in, in exactly the way a password would. There is no account because there is nothing to attach one to: the link itself carries the permission.
This is the same mechanism behind a shared document link or an emailed sign-in link, and the security argument is identical. The token is the credential. That is a fair trade when the controls around it are right, and a bad one when they are missing.
The three safeguards that make it safe
- Scope. A link should carry only the access its holder needs. The contractor who needs to see the finish schedule does not need your budget. A tool with one all-or-nothing link forces you to over-share every time you share at all.
- Revocation. You must be able to kill a link instantly, without disturbing the others. Relationships end, phones are lost, and a link forwarded to a spouse's work email is now in a system you do not control.
- Expiry. A link that outlives the project is a permanent hole. An expiry date closes it without anyone having to remember.
Which tools work this way
Checked on each vendor's own public page on 2026-08-12: Programa states that clients access their dashboard via a secure link with no account required. Planify describes a Magic Link opened in any browser with no account creation, no password and no email verification. NYA uses a tokenized link per project, with named links, per-link scopes and revocation.
DesignFiles advertises a "unique client login" instead. Houzz Pro and Studio Designer describe client approvals in detail but do not state on their public pages whether an account is required, which is a question worth asking their sales teams directly rather than assuming either answer.
What to send with the link
A bare URL in an empty email reads like phishing, and cautious clients treat it that way. Send it from an address they recognise, say in one line what is waiting and what you need — "the living room selections are ready; approve or ask about anything by Friday" — and tell them it will open without a password. That last clause prevents the reply asking for login details.
When the link genuinely does not work
Roughly the same four causes account for nearly every "your link is broken" message, and none of them is a bug in the software. Knowing them saves a support round trip:
| What the client says | Usual cause | What to do |
|---|---|---|
| "It says not found" | The link was revoked, expired, or the project was reissued a new one | Issue a fresh link rather than debugging the old one; the old token is dead by design |
| "It opens a blank page" | A corporate mail gateway rewrote the URL and truncated the token | Send to a personal address, or send the link over text |
| "I never got it" | Spam filtering, most often on a first send to that address | Ask them to check spam, then send the same link a second way |
| "It won't let me approve" | The link was scoped to view-only | Check the link's scope before assuming a fault; view and approve are separate permissions |
Where a link is the wrong tool
Link access suits design decisions well because the worst case of a leaked selections link is that someone sees a sofa. It stops suiting the job as the stakes rise. Anything involving identity documents, stored card details or a signature with legal weight deserves a stronger check than "whoever has the URL", and a serious e-signature flow will verify the signer's email rather than trusting the link alone.
The practical rule: use links for everything a client should be able to do from their sofa in thirty seconds, and require something stronger the moment money or identity is involved. Most products in this category draw the line in about that place, and it is worth checking that yours does before you assume it.
Common questions
- Is a no-login client portal less secure than one with accounts?
- It is a different tradeoff rather than a strictly worse one. Accounts move the risk to passwords, which clients reuse and forget; links move it to the URL, which can be forwarded. A scoped link with an expiry and a revoke button is defensible for design selections. Neither model is appropriate for storing identity documents or payment credentials.
- What happens if my client forwards the approval link?
- Whoever holds it has whatever access that link carries — which is exactly why per-link scope matters. It is also why one link per person beats one link per project: if a link is loose, you revoke that one and reissue it without disrupting anyone else.
- Can I see whether the client opened the link?
- In most systems, yes — and it is more useful than it sounds. A client who has not opened the link is a reminder problem; a client who opened it three times and approved nothing is a hesitation problem. Those need different follow-ups.
- Do clients need an app to approve?
- No. Every product surveyed here opens in a browser, which matters because approvals overwhelmingly happen on a phone in the evening. An app download is the same friction as an account by another name.