Trust

Security at Tellane.

A demo platform holds pictures of your product, the people who looked at it, and keys into your CRM. Here is how we protect each of those — specifically, not in the abstract.

01

Captured screens never run on the app origin

Screens are served from a separate origin behind a content-security policy and shown inside a sandboxed frame. Anything captured from your product can’t reach your Tellane session, and nothing in a demo can reach another customer’s.

02

Every row belongs to a workspace

Every table carries a workspace id and every API query is scoped to the caller’s workspace from the first line. There is no “admin view” that spans tenants, and API keys can only ever see one workspace.

03

Secrets are hashed or sealed

Passwords are salted hashes. API keys and webhook secrets are hashed at rest and shown once. Secrets we must reuse — Slack hooks, HubSpot tokens, signing secrets — are encrypted under a key that lives only on the server.

04

Card data never touches Tellane

Paddle is the merchant of record: checkout, payment details, and the customer portal are theirs. Tellane receives signed webhooks about the subscription and nothing about the card.

05

Webhooks you can verify

Every delivery is signed with HMAC-SHA256 over a timestamp and the raw body. The reference shows the ten-line verifier; replayed or forged deliveries fail it.

06

Built to stay up under load

Public endpoints are rate-limited by address, traffic passes through DDoS mitigation before it reaches us, and captured screens are served from a cache so a demo going viral never competes with the app.

Accounts and access

  • Email addresses are verified before an account can sign in. Sign-up with an address that already exists never reveals that it exists.
  • Two-factor authentication with an authenticator app, single-use backup codes, and an emailed fallback code; five wrong codes lock the factor for 15 minutes. Trusted devices are remembered for 30 days at most.
  • Every signed-in device is listed with its address under Settings → Profile and can be signed out individually. Changing a password revokes every other session.
  • Three roles — admin, editor, viewer — enforced on the server for the dashboard, the API, and the auth client alike. A workspace can never lose its last admin.
  • Sign-in, password reset, the lead form, and the contact form are rate-limited by address.

Data in transit and at rest

  • TLS everywhere. Custom demo domains get their own certificate automatically.
  • Databases and storage are not reachable from the internet; only the application can talk to them.
  • Captured screens use unguessable keys; deleting a screen deletes the file.
  • Workspace exports are stored privately, never on the public screen origin, and expire after seven days.
  • Encrypted backups, taken regularly and retained for a limited period.

API and integrations

  • Keys come in two kinds: tl_live_… can edit, tl_test_… can only read. Neither can touch the team, billing, other keys, or integrations.
  • 600 requests a minute per key with X-RateLimit-* headers, so a leaked key is bounded as well as revocable.
  • Webhook endpoints must be https. An endpoint that keeps failing is paused automatically and every admin is emailed.
  • The MCP server is read-only and key-authenticated.

Viewer privacy

The player stores one random id in local storage and no cookies. Events carry device class, referrer, and a city-level location derived at the edge; raw IP addresses are not written to analytics. Details are in the privacy policy.

Reporting a vulnerability

If you find something, email [email protected] with enough detail to reproduce it. We acknowledge within two business days, keep you posted while we fix it, and credit you if you'd like. Please give us reasonable time before publishing, don't access other people's data beyond what's needed to demonstrate the issue, and don't run denial-of-service or social-engineering tests. Good-faith research under these rules will never lead to legal action from us.

Out of scope: rate-limit findings on public forms that require thousands of requests, missing best-practice headers on third-party hosts, and reports from automated scanners without a working proof of concept.