Glossary
Every Inboard term in plain English — the words you'll see in the dashboard, and the internal words you might hear from us, all mapped to what they actually mean.
This page defines every term Inboard uses, in plain English. The first table covers the words you'll meet day to day in the dashboard and widget. The second covers internal words you might run into in a support thread, a changelog, or the admin tools — each mapped to the customer-facing idea it stands for.
If a term has its own page, the entry links to it.
Terms you'll see
These are the words that appear in the product. The five core entities are covered in depth in Core concepts.
| Term | What it means |
|---|---|
| Project | The top-level container for one product integration. Owns branding, allowed domains, team, and exactly one widget style. One product, one project. See Projects. |
| Install template | The configured set of requirements an installer must complete to set up your product, in order. A project can hold several. Formerly called "Setup" or "Guide." See Install templates. |
| Requirement | A single thing the installer has to do — paste a snippet, add a DNS record, enter an API key. Each requirement has a type (see the next row). |
| Requirement type | The kind of a requirement, which decides how the widget presents and verifies it: code snippet, DNS record, API key, command, download, webhook, HTTP check, or custom verify. See Requirement types. |
| Variable | A named placeholder — a domain, an API key, an account ID — that gets filled with a real value per installer so guides are copy-paste-ready. See Variables. |
| Widget | The embeddable end-user UI that renders the guide, detects the installer's platform, and runs verification. Vanilla JS, Shadow DOM, under 30 KB gzipped. See The widget. |
| Installer | The end user setting up your product — your customer's customer. The widget is built for them. |
| Platform | The specific tool or host the installer is using (Cloudflare, WordPress, Vercel, GoDaddy…). The widget auto-detects it where it can, or asks. See Multi-platform support. |
| Verification | The check that confirms a requirement was actually done, so the installer gets a green tick instead of a guess. See Verification methods. |
| Allowed domains | The list of domains the widget is permitted to load on, set per project. A request from anywhere else is refused. See Projects. |
| Widget style | The branding, colours, and layout for a project's widget. There is exactly one per project — see one widget style per project. |
| Session | One installer's run through the widget. Sessions are what analytics counts and what billing meters. See Analytics and Billing. |
| Snippet signing | A signature on your embed snippet that lets the widget prove the script wasn't tampered with in transit. The customer-friendly side is covered in Account & security. |
Terms you might hear from us
These words live in our admin tools, changelogs, and engineering. You never have to use them — but if one turns up in a support reply or release note, here's what it actually means for you.
| Internal term | In plain English |
|---|---|
| Resolver | The engine that turns one of your requirements, plus the chosen platform's instructions and the installer's variable values, into the exact steps shown in the widget. It's why the same requirement reads differently on Cloudflare than on GoDaddy — you configure once, the resolver tailors per platform. |
| Instruction / platform instruction | The platform-specific recipe we maintain for a requirement type — e.g. "how to add a DNS record on Namecheap." You pick requirements; we keep the per-platform instructions behind them current. |
| Instruction version | A specific, dated revision of a platform instruction in our knowledge base. We version them so guides stay correct as platforms change their UIs, and so we can roll a bad change back. You always get the published version. |
| Knowledge base (KB) | Our curated, version-controlled library of every platform instruction. It's what lets us add new platforms without you changing anything. |
| Hydrated instruction | An instruction with all its internal references (images, shared assets) swapped for real values, ready to be rendered. An intermediate step you'll never see directly. |
| Render block | One typed piece of a rendered step — a paragraph, a code block, a callout, a link, an image, a DNS-record table, or a verification check. The widget draws a guide by laying out render blocks in order. |
| Payload slot | A marker we place inside a platform instruction that says "the installer's specific value goes here." At render time the resolver drops the real payload (your snippet, their DNS record) into the slot. |
| Rendered instruction / rendered install template | The finished, installer-ready output for one platform — every requirement resolved, every variable filled, ready for the widget. The end product of everything above. |
| Resolver registry | The internal lookup that matches each requirement type to the resolver that knows how to render it. Plumbing. |
| Auto-detection | How the widget guesses the installer's platform from signals in the page or environment, so it can skip straight to the right guide. Falls back to asking when it can't be sure. See Multi-platform support. |
| SRI (Subresource Integrity) | The browser-standard hash behind snippet signing — it lets the installer's browser refuse a tampered widget script outright. |
Words we've retired
| Old word | Use instead |
|---|---|
| Setup | Install template |
| Guide | Install template (the rendered output is just "the steps" or "the guide the installer sees") |
Spotted a term in the product that isn't here? Tell us and we'll add it.