Secure entry
The secret is typed on our page; a sealed envelope travels back to you
A password, an access key, any data: the person types it on a Sealform page, and a sealed envelope travels back to whoever asked β only they can open it. Nothing of it is left in the chat or in anyone's logs.
Why
What is wrong with a secret sent in chat
A password sent as a message stays in the chat forever β with you, with the other side, in the messenger's logs and in backups. Deleting the message is not enough: the copies have already spread.
How it works
Three steps
You ask
Your product opens a request and gets a link.
The person types
They open the link and type the secret on a Sealform page.
A sealed envelope reaches you
What was collected is sealed with the public key you brought. Only it can open it.
The second of truth
The one who asked does the checking β while the person is still at the screen
It did not work β they retype it right there, instead of learning about broken access tomorrow.
Two kinds
Secret and questionnaire
The kinds do not mix.
Secret
A password, an access key. It reaches only you, only as a sealed envelope.
Questionnaire
Ordinary answers: choices, ratings, pictures. They come back open to whoever asked.
A questionnaire that declares even one secret field is never created at all β the seam between the kinds is impassable by construction.
Connect
A consumer opens a request with its key
- The form description is JSON Schema: an ordinary standard, not our library.
- What was collected arrives as a sealed envelope that your key opens.
- Your code does the checking and reports the outcome β while the person is still at the screen.
