Security

Last updated 16 October 2026

What we do to keep your account, your keys and the people who write to you safe. The binding version is section 5 of the data processing agreement, and this page never promises more than it does. Questions, or something to report: [email protected].

Where your data lives

The service and its database run on servers in the EU. Cloudflare sits in front of them for TLS and a web application firewall. The files sent with messages are kept in a private bucket at OVHcloud in Frankfurt, Germany, or, if a workspace on Business chooses, in its own Google Drive, Dropbox or bucket. Paid plans are sold by Paddle, our merchant of record, so card details never reach our servers.

Your customers

• A live key works only on a site whose domain you proved, by a DNS record or a file on the site. For an app with no website, it works only for people your server signed in, or for a phone holding the key your app made for it, and nothing is emailed. A test key works anywhere, and its tickets are test tickets that mail nobody.
• Our script swaps the key for a session that works only from that site and lasts thirty minutes. It keeps the session in memory and uses no cookies.
• A guest's new ticket costs their browser a small proof of work, used once, so a script can't flood your form.
• Someone is a logged-in user only when your server signed a token for them with the secret we gave you. Anyone else is a guest, and your team sees them as one.
• Our script builds the form one element at a time and never from markup, so it works under a Content-Security-Policy that allows only our script and our API, and nothing anyone wrote runs on your page. A form of your own HTML and CSS is cleaned on our server and rebuilt from an allowlist again in the browser.
• What a visitor types before pressing Send, to be shown help articles or to search your help page, is used to find articles and then dropped. It is never stored or logged, and it travels in the request's body, never in an address.
• A customer's email address is kept encrypted. The first mail to it is a fixed confirmation with nobody's words in it, and nothing else is mailed until they press Confirm.
• The link in a mail carries its key after the #, which browsers send to no server, so no server's log holds it. When it opens on your own help page, our script takes it out of the address as soon as it loads.
• A reply to one of our emails, and your support mail forwarded to us, arrive in a Microsoft 365 mailbox of ours, and we delete each one as soon as we have read it: no mail program sees it again, and Microsoft removes it for good after its deleted-item time, 14 days unless we shorten it. We keep what was written above the quoted email, with the ticket, and nothing else of the email.
• A file is accepted by what its bytes are (pictures, PDF, plain text, zip), never by what the sender says it is, and SVG and HTML are refused. It is handed out only by a link that works for one minute, as a download from the storage's own address. A file kept in a workspace's own store is fetched through us for that one download, checked to be what was sent, and kept nowhere.

Integrations, buttons and webhooks

• What your URL answers about a customer is shown to your agent and kept nowhere: not in our database, our logs, an error or a metric. A test plants a marker value and searches every table and log line for it.
• We call your URL only about a customer your site signed for, sign every call with your secret and a timestamp, and send it nothing until it passes a connection test.
• A button runs only after the agent types the word it asks for. Each press reaches your URL once and leaves a line in the audit log, and we never retry one.
• A webhook to your own URL is sent nothing until your server answers a signed test, and every event is signed. A Zapier, Make or n8n Cloud address must be theirs.
• Every call we make to an address outside our network leaves from a separate process with no access to our database or our secrets. It reaches only public addresses, never our own machines, with a size cap and a time limit.

Your team's accounts

• You sign in with a one-time code we email you, so there is no password to leak. The code is stored only as a keyed hash, lives ten minutes, and five wrong guesses burn it. Asking for a code answers the same whether or not the address has an account.
• Before a code is sent, a bot check (Cloudflare Turnstile) makes sure a person is asking, and codes are limited per connection and per address.
• Two-step sign-in with an authenticator app is on every plan. Once it is on, the app's code takes the emailed code's place, with ten backup codes that each work once. Five wrong codes in fifteen minutes, or twenty in a day, pause signing in to that account, and you are emailed when that happens. Turning it on or off signs out your other sessions.
• On Business you can require two-step sign-in for everyone in the workspace, and sign your team in through your company's own provider over OpenID Connect, for an email domain you proved in DNS and we check again daily. A session from your provider lasts a day, and requiring it signs out everyone else at your domain.
• Workspaces have owner, admin and agent roles, and on Business roles of your own, which can see fewer tickets or write private notes only. What binds the workspace stays the owner's: billing, keys, integrations, secrets, roles, the audit log, two-step sign-in and single sign-on.
• Making or changing a secret, a credential, or where your tickets are sent asks you to have signed in within the last thirty minutes.
• “Sign out everywhere” ends every session at once.
• An audit log records who changed what, on every plan, and you can read it from Pro.

Keys and AI assistants

• A publishable key (pk_live_, pk_test_) only says which site a form belongs to.
• Your identity secret and your integrations' secrets are shown once, when they are made.
• Account API keys (hpk_) are scoped, shown once, stored only as hashes and revocable, and can never hold the riskiest permissions.
• AI assistants connect with OAuth 2.1 and PKCE, from Pro. The person approving one chooses what it may do, and running buttons, changing secrets and opening files start off. It acts with that person's own role, can be cut back or disconnected at any time, and your workspace chooses who may connect one.
• We run no AI ourselves and send nothing to an AI company. An assistant your team connects is yours, and it sees only what its person could see and allowed.

What we encrypt

• Everything travels over TLS.
• On our servers, customers' email addresses and every secret and credential you give us are encrypted with AES-256-GCM, each bound to its workspace so a copied row opens nowhere else.
• Webhook and chat addresses, your Twilio or Vonage credentials, your mail server's password and your single sign-on client secret are never shown back once saved. A key you give us to bring tickets over from another helpdesk is erased when the import ends.
• The mobile number of someone on call is encrypted and shown only to them, by its last three digits. A browser's address for notifications is encrypted too, and each notice is encrypted so that only that browser can read it.
• Messages and replies are kept as written, so you can search your tickets.

How we run it

• TLS on every connection, with HSTS. The portal loads scripts only from its own address, and no other site can frame it.
• Server secrets are kept encrypted, out of the code and the database.
• The API runs in a minimal container image as a non-root user. Every image is scanned for known vulnerabilities before it deploys, and a release to production first passes a dependency audit and an active web security scan of the same build.
• Public routes are rate-limited, and the counters are stored under a keyed hash, never an IP address or an email in the clear.
• Our request logs record which route was called, never the full path with its ids or tokens, and never a word of a ticket.
• Our operator console and its API answer only on our private network. The console asks for an authenticator code at every sign-in, shows account facts and counts and never what anyone wrote, and records every change made from it. The production database publishes no port.
• The database is backed up every night, and each copy is kept for up to thirty days.
• Closed tickets are deleted after your plan's period, test tickets after a week, and a deleted account's workspaces thirty days after it is deleted.

If something goes wrong

If a breach affects personal data we hold for you, we tell you without undue delay, as the data processing agreement sets out.

Report a vulnerability

Email [email protected] with what you found, how to reproduce it and what it affects. Please test in a workspace of your own, touch no one else's data beyond what shows the problem, don't degrade the service for others, and give us the chance to fix it before telling anyone. Good-faith reports are welcome, and we will tell you what we do about yours.

Machine-readable contact: /.well-known/security.txt.