Receiving a Secure Request

Someone asked you for a credential through CredenShare. This page is for you, the person filling the form in — no account and no prior knowledge assumed.

What the link is

A CredenShare user created a secure request: a short form that collects a specific credential — a password, an API key, a licence key — instead of asking you to send it by email or chat. The link they gave you looks like /r/ followed by a short code: the app builds it as https://crs.sh/r/<code>, and the same page also opens on app.credenshare.io.

Opening it shows the title they gave the request, any instructions they wrote, and one box per item they asked for. Nothing you type is sent until you press Submit Securely.

The reason they used it is that an email or a chat message keeps a copy of your credential in a mailbox, a channel and a backup, indefinitely. A secure request deletes your answers on a schedule the sender sets instead — see How long it lasts.

You do not need an account

Filling in the form is free, requires no sign-up and installs nothing.

There is one exception. The person who created the request can require a CredenShare login, in which case you see Login Required and "You need to be logged in to submit this request." Either register a free account, or ask whoever sent the link to turn that setting off — they can change it on the request they already made, and the link stays the same.

These two settings can also stand between you and the form, and both are normal:

Before you fill it in

The fields are chosen by whoever created the request, not by CredenShare. We do not vet what a request asks for, so the question to ask is whether you trust the person who sent you the link — and if you are not sure, confirm with them through a channel you already use, not by replying to the message that carried the link.

Two things are worth checking:

• The domain. A genuine link is on crs.sh or app.credenshare.io. Nothing else is ours.
• The branding. The page may carry the sender's own logo and colours — Business and Enterprise accounts can brand the form. Branding is not evidence either way. The domain is.

What happens to what you type

When the request carries a public key, your answers are encrypted in your browser, before anything is sent. Every request created in the CredenShare web app or through the CredenShare REST API carries one.

Such a form arrives carrying a public key that belongs to the request. When you press Submit Securely, your browser generates a one-time key pair, combines it with the request's public key to derive an AES-256-GCM key unique to your submission, encrypts your answers with it, and sends only the result. You will see "Encrypting and submitting..." while that happens.

The key that decrypts such a submission is not sent to us in a form we can open. Because every submission gets its own one-time key pair, one person answering a request cannot read another person's answers either.

A request without a public key — one created through CredenShare's MCP server, for example — cannot currently take submissions, and the form does not tell you so: its protection panel reads "AES-256, end-to-end" either way. Pressing Submit Securely sends your answers over HTTPS without the in-browser encryption step, our server refuses them, and you see "Failed to submit. Please try again." Nothing is stored, so any submission that reaches "Submitted Successfully!" was encrypted in your browser first. Tell the sender; a request they create in the CredenShare web app carries a key.

Who can read your submission

The person who created the request. For a request that carries a public key, the key to read submissions stays with them — in the private access link the web app gave them, or wherever their own code keeps it — and was never sent to us. If they created the request in the CredenShare web app and use zero-knowledge custody, or their own integration sent us a copy for their account, we also hold a copy of it, sealed to their account key, which opens only with a secret we do not keep — their passphrase, which never reaches us, or the custody secret of an API key they granted account custody, which we generate when that key is created, return once and never store. So for such a request we hold only ciphertext, and nobody who merely has the link you were given can read anything. We return that sealed copy to the requester's signed-in CredenShare session, not to an API key, so granting a key account custody does not on its own let it open your submission.

That holds inside their team too. If the request was created in the web app for a team whose account uses zero-knowledge custody — a Business and Enterprise feature — the requester's key is also wrapped to the team, but opening submissions is checked against the account that created the request, so their colleagues, team admins included, cannot open yours.

Alongside your answers, they see your IP address — or your email address, if you were signed in to a CredenShare account when you submitted. If the request is answered by several people, each submission is listed separately.

When your submission arrives, the requester gets a notification inside the app. They also get an email, unless they turned that setting off when they built the request.

How long it lasts

Two separate clocks apply.

The form. The sender sets an expiry date on the request, and can also cap the number of submissions it accepts. When either is reached the link stops working and shows "This request is no longer available".

Your submission. Its content is deleted automatically after the lifetime set on the request when you submitted: hours up to 24, days up to 31, or months up to 3. The sender also chose when that countdown starts: when you submit, or when they first open your submission. In the second case the countdown waits for them, but not indefinitely. If they never open it, your submission is deleted 30 days plus that lifetime after you sent it. They can also delete it sooner, for example by expiring the request in the app. Once the content is deleted there is no undo. The sender keeps a record that you submitted and when, with your IP address, or your email if you were signed in, but not what you typed.

The form shows a panel headed How your submission is protected. Its Auto-scrub line always reads 7 days after submission, which is the default rather than a reading of what this sender set. If the exact lifetime matters to you, ask them.

You cannot edit or withdraw a submission once it is sent. If you entered the wrong value, open the same link again and submit the correct one — unless the request has reached its submission cap — and tell the sender which one is right, because both will be listed.

If the link does not work

Three messages are worth telling apart:

• "This request is no longer available" — the request has expired, hit its submission cap, or been deleted. The same card appears when the link is incomplete, so check first that you opened it whole, exactly as you received it; then ask the sender for a new one.
• "Unable to Load Request" — the form itself could not be loaded. The line under the heading says why; Try Again retries. If it reads "This request requires two-factor authentication. Enable 2FA on your CredenShare account, then refresh this page.", the sender restricted the request to accounts with two-factor authentication switched on.
• "Failed to submit. Please try again." — the form loaded but nothing was stored. If a retry fails too, the cause is on the requester's side, for example that their account has no share allowance left, or that the request has no public key. Tell them; nothing reached them.

If none of those fits, see Link not working.

Still stuck, or unsure whether the request is genuine? Write to support@credenshare.io.