Security: server vs browser

A key in a web page can be read by anyone who opens it. So keys only ever live on your server, and the browser only ever gets a link that works once.

Your server onlyCopy Anchor Link

• Master key (master-priv-…): acts as the account owner.
• Embed key (hle_…): can only open embedded sessions.
• Creating, changing and deleting websites, setting credits and trials.
• Asking for the one-time link, after your own sign-in check.

Safe in the browserCopy Anchor Link

• The tracking pixel snippet: it only carries the website's public id.
• The one-time link: it works once, within 60 seconds.
• The messages the frame sends your page (ready, session-ended…).

NeverCopy Anchor Link

• A key in front-end code, a mobile app or a public repository.
• DELETE /admin/websites/{id}, or any write, from the browser: proxy it through your server after your own permission check.
• A websiteId taken from the request: always from the signed-in user's company in your database.
• One login shared between clients: one website and one client view each.
• scope: "account" for anyone but your own staff.

If a key leaksCopy Anchor Link

• Embed key: revoke it under Embed in your app → Server keys. Its open sessions end on their next request. Create a new one first to avoid downtime (up to 5 can be active).
• Master key: rotate it, see Authentication.

Before you go liveCopy Anchor Link

• grep your front-end build output for master-priv- and hle_: no hits.
• Signed out, your endpoint answers 401 without calling us.
• Sending another company's websiteId still opens only the user's own.
• The link response has Cache-Control: no-store and is never logged.

Next: build it with your AI coding assistant.