Inboarddocs
For SaaS owners

Account & security

Protect your account and prove to installers that your guides are safe.

Security in Inboard works on two levels: keeping your account safe, and giving your installers proof that what they're installing is genuinely from you and hasn't been tampered with. This page covers both in plain language.

For the integrator and verification detail behind these features, see Security.

Protecting your account

Multi-factor authentication (MFA)

Turn on MFA from your account settings. With MFA enabled, signing in needs both your password and a second factor (an authenticator app code), so a leaked password alone can't get into your account. We strongly recommend enabling it for every member of a project.

Mandatory 2FA at publish

Publishing an install template makes it live for real installers, so it's a sensitive action. Inboard requires two-factor confirmation at the publish step — even if you're already signed in, you confirm a second factor before a template goes live. This makes it much harder for anyone who gains brief access to your session to push changes to your installers.

Proving your install is safe

Before anyone embeds your install template, Inboard verifies you control where it runs and gives installers a way to check that the steps are authentic.

Domain ownership verification

Before you can publish, Inboard verifies that you own the domain the install template is associated with. This stops someone from publishing guides under a domain that isn't theirs, and it's a prerequisite for going live.

Snippet signing

When your install template includes a code snippet for installers to paste, Inboard cryptographically signs that snippet and shows the signature in the widget. The signature proves the snippet came from your account and hasn't been altered in transit. Installers don't need to understand the cryptography — they just see that the snippet is signed and trusted.

Public snippet viewer

Anyone can open the public snippet viewer to see exactly what a signed snippet contains before they install it. This transparency means a cautious installer (or their own security team) can audit precisely what's being added to their site, which builds trust and reduces support questions.

Change audit log

Every change to a published snippet is recorded in a tamper-evident audit log. Because each entry is chained to the one before it, the history can't be quietly rewritten — so you, and your installers, can always trust the record of what changed and when. This protects installers from silent, unauthorised changes to a snippet they've already trusted.

API access

Programmatic access to your account is available on the Business plan (Business plan). API credentials are write-scoped secrets — keep them server-side and never put them in client-side code. See Security for the difference between public embed keys and account API keys, and the API reference for usage.

On this page