Skip to content
CredenShare
Help

Help and Support

Troubleshooting and support — how to reach CredenShare, what to put in your message, what support can and cannot do, and where the rest of the help pages are.

Support runs on email. There is no ticket portal and no live chat.

Troubleshooting first

Most failures have a self-serve answer:

Where to write

AddressUse it for
support@credenshare.ioAnything wrong with your account, signing in, billing, or the product itself.
hello@credenshare.ioGeneral and sales enquiries. The form at credenshare.io/contact delivers to this address.
security@credenshare.ioSecurity reports and data-protection requests.

Enquiries are handled internally, so there is no portal to sign into and no ticket to look up. The only ways to reach us from inside the product are mail links: Contact support on the sign-in verification screen, and Support in the footer of a share page. Both open a message to support@credenshare.io.

What to put in the message

The more of this you include, the fewer round trips it takes.

  • The email address on your CredenShare account. If you are writing from a different address, say which account you mean.
  • The share short code, the eight-character code that identifies the share — for example AbCd1234. That alone is enough for us to find it. If you are not sure which part of your link the code is, describe the problem instead and we will ask: do not paste the whole link.
  • The exact message you were shown, copied character for character rather than described. The wording is what tells the failures apart.
  • Roughly when it happened, with your time zone.
  • Where it happened — the app at app.credenshare.io, a link you opened at crs.sh, a SecurePaste page, the widget on the homepage, the Slack app, or the API.
Never send us the secret itself, and never send us a full share link. Every link carries the key that decrypts your content — created in your browser and never sent to our servers, which is exactly why we cannot read what you share, and why forwarding a link to us hands over the one thing protecting it. Send the short code on its own. The same goes for the access link to a secure request. If you have already sent a full link to anyone, treat the credential as exposed and rotate it.

What support can do

  • Reset multi-factor authentication when you have lost every factor enrolled on the account and can no longer receive a code at your verified contact. Try the verification screen first: with both an authenticator app and email codes enrolled it shows Choose a verification method, so you can fall back to the other factor. Reset your password on that screen does not remove an enrolled factor — you will be asked for the same second factor at your next sign-in — so a lost authenticator is not solved by resetting your password. See Signing in.
  • Answer billing questions — charges, plan changes, and invoices you cannot account for. Your invoices are already listed under the Invoices tab of your Account page, and your current plan and payment card under Subscription. Payment is by card only: Visa, Mastercard and American Express.
  • Act on the account itself, including closing it. There is no self-serve account deletion in the app, so closure has to come through us.

What support cannot do

These are limits of the design, not of the support desk. No amount of escalation changes them.

  • Recover a zero-knowledge passphrase. It is generated in your browser, shown once, and never sent to us. The app is blunt about the consequence: without the old passphrase, "we cannot re-wrap your existing keys". We can neither look it up nor reset it. Zero-knowledge custody is a Business and Enterprise feature. See Zero-knowledge custody.
  • Recover an expired, deleted or destroyed share. Once a share passes its expiry, uses up its view limit, or is destroyed by too many wrong password attempts, the stored ciphertext is gone. There is no undelete and no backup copy to restore from.
  • Read the content of a share. Shares created from the web, the REST API or an SDK are encrypted in the client before they reach us; we hold ciphertext and never held the key. Shares created through the Slack app are the exception — those are encrypted on our servers, under a key in AWS KMS. See Encryption.
  • Tell a recipient why a particular link failed. Every failure shows the same card — "This share is no longer available" — whether the share expired, was deleted, never existed, or arrived with its key missing. Distinguishable messages would let anyone probe which short codes exist, so the ambiguity is deliberate and we will not resolve it for a caller we cannot place. Ask the sender to check the share and send a fresh link.

Start here

If you arrived from a link that no longer works, or from a message you do not recognise, these two pages answer most of it without an email.

  • A link is not working — written for the person who received a link, in likelihood order.
  • Error messages — keyed on the wording you were shown, so you can search for the sentence itself.

The rest of the help pages

PageCovers
Signing inPasswords, two-factor codes, and being locked out.
Plans and share allowanceHow many shares your plan allows, when the count resets, and why expired shares still count.
Billing and subscriptionUpgrades, downgrades, invoices, and cancelling.
Creating a shareEvery option in the create dialog, including the failed attempts tolerance.
Zero-knowledge custodyThe account passphrase, device activation, and what is lost if it goes.
Key conceptsShares, expiry, view limits and the access trail.
EncryptionWhere encryption happens and what we can see.
Errors and rate limitsThe developer view, keyed on integer error codes.