Secure Requests

A secure request is a form you send to somebody so they can hand you a credential, instead of you handing one to them.

Business and Enterprise only

Secure requests are gated on the secure_requests entitlement, which only Business and Enterprise carry — monthly and yearly alike. On every other plan the Secure Requests item is missing from the sidebar and from the command palette, and creating a request is refused, in the app and over the API. Opening the page directly shows an upgrade link instead of New Request.

Everything on this page is the owner's side of the feature. The person filling the form in has their own page: Receiving a secure request. The REST equivalent is documented separately under Secure requests.

When to use one instead of a share

Use a share when the secret is already yours and you need to move it to somebody. Use a secure request when the secret is theirs and you need it moved to you — a client's API key, a contractor's licence key, a vendor's SFTP password.

The difference that matters is which way the encryption points. With a share, you hold the key and the recipient gets it in the link. With a request, the submitter's browser encrypts to a public key belonging to the request, and only you can open the result. That is why the link you hand out carries no key material and can safely go into a ticket, a channel or an email thread — where a share link could not.

Creating one

Secure Requests → New Request opens the form. It is created in whichever workspace you are currently in — the badge in the modal header names it — so switch to the team first if the request belongs to the team.

• Title is required and accepts up to 255 characters. It is what the submitter sees at the top of the form, and it becomes the title of each submission ("Response to: your title").
• Description is optional; it renders under the title as instructions for the submitter.

Defining the fields

Under Requested Fields you list what you are asking for, one row per item. Every row needs a name — the create is refused with "All fields must have a name" otherwise — and each carries a type:

Drag a row by its grip to reorder; the order you set is the order the submitter sees. On Business and Enterprise the number of fields per request is unlimited, so the Add Field button never runs out.

Fields are asked, never answered in advance: a request has no notion of a pre-filled default value, and any default value carried by a template is ignored.

The two links

Creating the request produces two links from the same short code, and they are not interchangeable. The success screen labels them plainly:

Sending the access link to a submitter would hand them the ability to read every submission to that request. Saving only the collect link leaves you unable to read any.

Two things soften that, and neither is a substitute for saving the link:

• The seed is cached in the browser that created the request, so submissions open there without your being asked for anything. Clearing site data discards it.
• If you have set up zero-knowledge custody, the seed is also wrapped to your account key at creation — and, for a team request, to the team key — so your other activated devices resolve it without the link.

Editing a request never regenerates the keypair, so your access link keeps working afterwards. Title, description, expiry, submission cap, fields and the protection settings can all be changed; the key cannot. Only the account that created the request can edit it, and only while it is active. A teammate's request in a team list has no Edit button. Changes to the Submitted Data Settings apply only to submissions that arrive after you save.

Request lifetime and submission cap

Two controls decide when the form stops accepting anything.

Expires On is an absolute date and time. The Quick Set buttons fill in 7, 14, 30 or 90 days ahead at 12:00. Leaving the date empty defaults to 30 days from creation. After it passes the link stops accepting submissions; submissions already received are unaffected.

Max Submissions is off by default, which means unlimited. The slider runs to 100 and the number box beside it accepts up to 5000. The cap counts every submission the request has ever taken, including ones that have since expired — deleting or expiring a submission does not free a slot.

Request security

Three optional controls sit between the submitter and the form:

• Password protect form — a passcode the submitter must enter before the fields appear. Send it through a different channel from the link. Keep it to 72 bytes: that is 72 plain ASCII characters, or fewer if it uses accented letters, emoji or non-Latin characters. The app refuses a longer one when you save, and says why. It is stored as a one-way hash, so it can never be displayed back to you. On a later edit, leaving the box blank keeps the current password and unticking the checkbox clears it.
• Secure view prompt — a markdown message shown before the form opens, up to 500 characters. Use it for compliance wording or handling instructions.
• Submitter must be logged in — restricts submissions to signed-in CredenShare accounts, which attributes each submission to an email address rather than an IP.

What each submission becomes

Every submission creates a share that only you can read, and the Submitted Data Settings section decides how that share behaves. The server copies these settings from the request as each submission arrives, so a submitter can neither skip nor change them, including how long the submission lasts. Editing them later affects new submissions only. Submissions already received keep the settings they arrived with.

• Unit and Duration set how long the submission stays readable: hours up to 24, days up to 31, or months up to 3. The default is 7 days.
• Expire from chooses when the clock starts. Creation counts from the moment the submitter sends it. First View starts the countdown the first time you open the submission in the viewer. The expiry is stamped when the viewer fetches the submission. That comes after any secure view prompt and after you enter its password, even a wrong one, and before any Access link needed step. A First View submission you never open still expires, 30 days plus the chosen time after it was submitted, and opening it late cannot push it past that date. Until you open it, the list shows something like "Expires 7 days after first view, date at the latest".
• Password protect share adds a password you must type before a submission opens in the viewer. It can be up to 72 bytes: 72 plain ASCII characters, or fewer if it uses accented letters, emoji or non-Latin characters, which take two to four bytes each. The app refuses a longer one. It is matched exactly as typed, including any spaces at either end. It is stored as a one-way hash, so it is never shown back to you. When you edit the request, the form says "A password is set". Leave the box blank to keep it, type a new one to replace it, or press Remove password (or untick the box) to remove it. Submissions already received keep the password they arrived with.
• Secure view prompt adds a confirmation gate, with an optional message of up to 500 characters, before the content is displayed — useful when you might be sharing your screen.

Field templates

If you build the same request repeatedly, save the field set as a field template of kind secure request and pick it from the selector at the top of the create modal. The selector only appears when your plan includes field_templates and at least one template of that kind exists in your current context — team templates in a team, your own personal templates otherwise.

A template supplies the field names and types, and can also preset the submission cap, the form password flag, the login requirement, the secure view prompt and its message, and the submitted-share expiry. Anything it sets can be overridden before you create the request, and the small X beside the selector clears the applied template, returning the form to a single empty field.

Two ceilings apply, both from your plan:

The count cap is checked when you create a template, and the app refuses with "Your plan's field template limit has been reached."

What the submitter sees

They open the collect link, clear any gate you configured, and get the title, the description and one box per field, plus a panel headed How your submission is protected. That panel does not reflect your Submitted Data Settings: its Auto-scrub line always reads 7 days after submission, whatever you chose. If the lifetime matters to the submitter, tell them yourself. Every box has to be filled in. Pressing Submit Securely encrypts the answers in their browser before anything is sent, and they land on "Submitted Successfully!". No account is needed unless you required a login.

If the request has expired, hit its cap, or been deleted, all three look identical from their side: "This request is no longer available". Full detail is on Receiving a secure request — that page is written for them, so it is the one to forward when somebody is stuck.

How you are told about a submission

Two notifications, with different triggers:

• In-app. Every submission raises a notification reading "New response submitted by submitter for request title", linking to the request's page. This one is not optional.
• Email. Sent to your account address only when Notify me on submission is ticked, which it is by default. Untick it for a high-volume form.

Submitter is the person's email address when they were signed in, and guest when they were not.

Reading submissions

Open the request from the Secure Requests list to see every submission it has taken, newest first, with the submitter, the time, the expiry and the submission's own short code. The eye icon opens one in place.

The first time you open an end-to-end encrypted submission on a device that has neither the cached seed nor zero-knowledge custody, the viewer stops at Access link needed and asks you to paste the access link you saved. Paste the whole URL; it is cached on that device afterwards. A link belonging to a different request is refused rather than silently producing nothing.

Two further gates can precede that, if the Submitted Data Settings had them when that submission arrived: the secure view prompt, then the password. It is the password that was set then, even if you have since changed or removed it.

Export offers CSV and JSON for the whole request, but it does not use your access-link seed, so it cannot read end-to-end encrypted submissions, and requests created in the app are end-to-end encrypted. For those, the downloaded file currently holds no submissions, and the app reports "Exported 0 of m submissions" with "Some submissions could not be decrypted." Open end-to-end encrypted submissions one at a time in the viewer instead. Export covers active submissions only: with none available it refuses with "No submissions to export" and "Expired submissions are not exportable because their content is scrubbed."

A value you copy out of a submission is wiped from the clipboard 30 seconds later. The wipe reads the clipboard back first and only clears it if it still holds that value, so in a browser that blocks clipboard reads nothing is wiped.

Expiry and scrubbing

Submissions are shares, and they expire like shares. When one expires its content is deleted rather than archived, and nothing in the app or the API can bring it back. The row moves to an audit trail that keeps who submitted, when, and the submission's title and short code, but not the content. The list marks it expired, the eye icon is disabled, and hovering the date gives the exact timestamp. A submission whose countdown starts at first view expires its chosen time after you first open it, and no later than 30 days plus that time after it was submitted.

The request reaching its own Expires On date only closes the form, and so does expiring it through the API (DELETE /v1/requests/{shortCode} on an active request). The submissions carry on to their own expiries.

Using the delete control in the app is different. On either tab it moves every live submission into the audit trail before it touches the request, so expiring a request scrubs its submissions there and then rather than leaving them on their own clocks. Open what you still need in the viewer first: Export cannot read end-to-end encrypted submissions, so it is not a copy of them.

Open a request that is no longer active and the page replaces its title, fields and link with a banner saying the request "has expired or been deleted", with its submissions listed underneath. Go by each row rather than the banner: a row marked expired cannot be opened, while any other row opens as usual until its own expiry, which is what you will see after a request reaches its Expires On date or is expired through the API. Once a request has been permanently deleted, its submissions are no longer listed.

Expiring and deleting a request

The delete control means two different things depending on which tab you are on, and the confirmation dialog says which:

• Active tab — "Expire request now?" The request stops accepting submissions and moves to your Expired list. The dialog says submissions already received "stay available in the audit trail": the audit rows do stay, but their content is scrubbed at the same moment.
• Expired tab — "Delete expired request?" The row is permanently removed. Any submission still live is scrubbed first, as above, and afterwards the request's page no longer lists its submissions. This cannot be undone.

Either way the submissions' content goes, so open anything you still need in the viewer before you use the control. Do not rely on Export for end-to-end encrypted submissions; it leaves them out.

The top bar's emergency expire button does the same to your personal requests in bulk: for each one whose expiry date has not yet passed, it scrubs every live submission and then expires the request. Team requests, and personal requests already past their expiry date, are left alone.

Submissions count against your allowance

Every submission creates a share, and that share is charged to your plan's allowance, not the submitter's — they may not even have an account. A request answered by twenty people is twenty shares against your month. That bites on Business, whose allowance is 500 shares per billing month. Enterprise is unlimited, so a request there cannot exhaust one.

The check runs against the request owner's subscription, or the team's when the request belongs to a team. Expired and deleted submissions still count, exactly as expired shares do; see Plans and share allowance.

When the allowance is spent the submission is refused server-side and the submitter sees only "Failed to submit. Please try again." — they are not told why, and nothing reaches you. If people report failing submissions on a request that used to work, check your remaining allowance first.