Onboarding — what you need from a client

Every project needs things only the client has: hosting access, brand assets, a decision about who signs work off, and usually a credential or two. Onboarding is one page for all of it — a list of what's outstanding, with the secrets collected safely rather than ticked off from a chat message.

Open a project and go to Onboarding.

The list

Add anything you're waiting on, with a note and a category. If you're starting from scratch, Start from a common list fills it in for you — and it's tailored to the kind of project. A construction job gets site access, drawings and planning references; an app gets developer account access and store listing copy; a website gets hosting, DNS and analytics. A few things everyone needs — a main contact, who signs off, brand assets — appear whatever the type.

Pressing it twice is safe. It skips anything already on the list, including something you typed yourself.

Each item is Needed, Requested, Received or Not needed. "Not needed" matters more than it sounds: deciding you don't need something is a real answer, and deleting the item would lose the record that you considered it.

While anything is outstanding, the project overview says so and links back here. Once everything is in, the nudge disappears — a card telling you all is well is a card in the way.

Three kinds of thing, handled differently

Not everything you need from a client is a secret, and treating a set of brand colours like a production API key is wrong in both directions — it throws away things you need to keep, and it makes the client's page sound alarming about a question that isn't.

Each item has a kind, which decides everything that follows:

• A secret — an API key, a password, a login. Encrypted on arrival, read once, then destroyed. Owner or admin only.
• A file or asset — brand assets, content, a document. Uploaded and kept, filed with the project so it shows up in Files alongside everything else.
• An answer — a decision, an account name, a piece of information. Written down and kept on the item.

The starter list picks a sensible kind for each thing, and you can change it when you send the request.

Asking

Press Request securely on an item and the client gets a link. The item moves to Requested, and flips to Received on its own when they reply — you never keep the two in step by hand. If the link expires before they use it, the item says so, and the fix is to send a fresh one.

To ask for several things at once, select them and use Request together. They share one link and one email, so a six-item list doesn't mean six emails. Each item is still handled by its own kind, so a secret in the batch is destroyed while the brand assets beside it are kept.

What the client sees

One page, no account. It names what's being asked for — not the word "credential", which is only right for one of the three kinds. Where a file makes sense they get an upload box; where it doesn't, they don't, because inviting someone to upload passwords.docx is worse than having them paste the key.

They can also mark anything as sensitive. That escalates it: it's encrypted, shown to you once, and destroyed — even if you only asked for an answer. They can make it stricter, never looser, so nobody can quietly shorten how long an asset you're relying on is kept.

What's kept and what isn't

Worth being precise, because this is where the earlier version got it wrong.

Kept indefinitely: the checklist itself, files, answers, and the whole audit trail. An expiry is a deadline for the client to reply, not a shelf life for what they sent — something that arrived on time is kept.

Destroyed: secrets, and anything the client escalated. Read once, then gone, with the record of what happened left behind.

The rest of this article is about that destroyed half — because getting hold of a credential is the awkward part. Most of the time it arrives by email or chat and then sits there: in their sent folder, your inbox, a mail server, and every backup either of you has, for years. A link replaces that.

Asking for one

From a checklist item, use Request securely. For a one-off that never needed a line on the list, Request something one-off at the bottom of the page does the same thing.

Set the kind to A secret for anything that should be destroyed after you read it.

• What do you need? — a plain description the client will read, like "Google OAuth client ID and secret".
• Anything they need to know — optional, and worth using. "Both are under APIs & Services → Credentials" saves an email.
• Email it to — sends them the link. Leave it blank and copy the link out yourself instead, if you'd rather send it through a channel you already use.
• Expires after — days. If nobody answers, the request dies on its own.

What the client sees

A single page, no account, no sign-up. It tells them what's being asked for, who's asking, when the link expires, and what happens to what they send.

The link only accepts a value. It cannot be used to read anything back, so forwarding it to the right person inside their company is safe.

If they need to send several things — a client ID and a secret, say — they go in the same box on separate lines.

Reading it

When it arrives you get an email saying so. The email never contains what they sent, deliberately: putting it there would copy it into an inbox, which is the thing this whole feature exists to avoid.

Open the project's Onboarding page and press Reveal. Copy the value somewhere permanent — your password manager, your server's environment file — and then press I've saved it — destroy now.

Revealing does not destroy it immediately. A stray page refresh would otherwise lose something the client cannot send again. If you forget to confirm, it is destroyed automatically about half an hour after you first opened it, and the record of what happened stays behind.

Only owners and admins can reveal a secret. A kept answer is ordinary project information and anyone who can edit the project can read it — gating that behind a role would be theatre that sends people back to asking on email.

Anyone who can edit the project can ask for one — that's ordinary project work — but reading it is the moment a secret is on a screen, so it's kept to the people accountable for it.

What we do and don't promise

Worth being precise, because this is the part that matters.

What's true. The credential is encrypted the moment it arrives. It never appears in an email or a notification. It is destroyed when you confirm you've saved it, when the reveal window lapses, or when the request expires unanswered — whichever comes first. Most of the time this table holds no secrets at all, only a record of what was asked for and when.

What isn't. This is not zero-knowledge. The value is encrypted with Waymarq's own key, not one only you hold, which means Waymarq is technically able to decrypt it while it is stored. What limits the exposure is how briefly it's kept, not an inability to read it.

So: better than email, by a distance, because email keeps copies nowhere anyone can clear out. Not a replacement for a password manager, and not the right tool for a secret that should never touch a third party at all — for those, use your password manager's own sharing and send nothing through us.

We'd rather say that plainly than let a security claim do more work than it has earned.

The audit trail

Every request keeps its metadata permanently: what was asked for, who asked, where it was sent, when it arrived, who read it, and when it was destroyed. None of that includes the value, so the trail is safe to keep and useful to have when someone asks in six months how a key was handed over.