Verification
Confirm each step was done correctly, and catch problems before they pile up.
Verification is how an install template proves a step actually worked rather than just trusting that the installer clicked "done". Inboard's north star is that a non-technical user finishes the install with confidence — so you validate progress at the points where it matters, and surface help the moment a check fails.
The four methods
Every requirement that needs confirmation uses one of four verification methods.
- HTTP check — Inboard automatically probes a URL or endpoint and confirms the install from the response. Best when correctness is observable from the outside: a snippet is live on the page, a DNS record resolves, a webhook responds.
- Self-report — the installer manually confirms they completed the step. Best for actions Inboard can't observe, like a setting toggled inside a third-party admin panel.
- Custom check — a custom server-side validation decides pass or fail. Best when "correct" depends on logic only your backend knows, such as whether an API key is valid and scoped correctly.
- None — no verification. Best for purely informational steps, or steps whose success is obvious to the installer.
What the installer experiences
With an HTTP check or custom check, the installer completes the step and the widget runs the check for them — they see a clear pass or fail without doing anything extra. With self-report, the widget shows a confirmation control the installer ticks themselves. With none, the step simply advances.
When an automated check fails, the widget doesn't dead-end. It surfaces fallback help — guidance on what likely went wrong and what to try next — and lets the installer re-run the check after fixing it. That fallback is what keeps a non-technical user moving instead of getting stuck.
Choosing a method
| Method | Who confirms | Use it when |
|---|---|---|
| HTTP check | Inboard, automatic | Success is visible from a URL or endpoint. |
| Self-report | The installer | The action happens somewhere Inboard can't see. |
| Custom check | Your server | Pass/fail needs your own validation logic. |
| None | Nobody | The step is informational or self-evidently done. |
Prefer an automated method (HTTP or custom check) at the meaningful checkpoints — the moments where a wrong setup would otherwise go unnoticed until much later. Reserve self-report for steps Inboard genuinely can't observe, and none for steps that don't need a gate at all.
Where to go next
- HTTP check requirement — set up an automatic URL probe.
- Custom verify requirement — wire a step to your own server-side validation.