Embeddable onboarding checklist

An onboarding checklist you can embed in an afternoon.

One <script> tag adds a checklist that docks to the right on desktop and turns into a peek bar above your bottom nav on mobile. Progress is kept per end-user, so it survives sign-in and follows them between devices.

In your app

<script
  src="https://gettingstarted.marthaia.com/sdk/v1/gs.min.js"
  defer></script>

<getting-started
  endpoint="https://gettingstarted.marthaia.com"
  project-key="pk_your_publishable_key"
  user-id="{{ current_user.id }}"></getting-started>

12 KB gzipped Zero runtime dependencies Runs on your own server

Create an account See the API

This is the widget, running live

The real bundle, mounted in a mock app. Configured from a draft payload — no key, no network, nothing leaves your browser.

Desktop — a panel docked to the right of your app

How it works

Describe the checklist

In the console you add steps, write their texts in as many locales as you support, pick the colours, and choose which edge the panel docks to. Each step has a stable key — that key is what progress is recorded against.

Open the console →
Drop in one tag

The snippet above is the whole integration. The element reads its config, generates a visitor id for anonymous users, and renders. Pass your own user-id whenever you know who is looking.
Report progress when it happens

The widget reports clicks itself, but the interesting moments are usually server-side — a payment settled, an integration connected. Say so from your backend with a secret key:
From your backend
```
curl -X POST https://gettingstarted.marthaia.com/api/gs/v1/server/complete \
  -H "X-GS-Secret: sk_your_secret_key" \
  -H "Content-Type: application/json" \
  -d '{"userId":"u_1234","stepKey":"first_payment"}'
```

What you get

Progress per end-user: Anonymous visitors are tracked by a generated id. Hand over a user-id and the anonymous history is merged into it once, so someone who started before signing up keeps what they finished.
Per-step translations: Label, description, done text and button text, per locale. The subtitle is plural-aware, so “2 actions left” is a sentence you write once.
Theming that stays yours: Colours, radius, font, panel width and stacking order come from the project config. The widget renders in a shadow root, so its styles and yours cannot collide — and custom CSS is there when you need it.
Events, not polling: Step clicked, step completed, everything completed, dismissed, and errors — each a DOM event you can hand to your analytics. An SSE stream carries changes made on the server.
Two shapes, one component: A collapsible panel docked left or right on desktop; a peek bar above the bottom nav that expands into a sheet on mobile. The layout is configuration, not a second integration.
Nothing to build: A custom element that runs from a script tag with no bundler and no framework. A thin React wrapper ships in the same repository if you would rather pass props than attributes.

The API

Everything the widget does is a documented HTTP call you can make yourself. Browser calls use the publishable key; backend calls use the secret key, which never leaves your server.

Endpoint	What it does
`GET /api/gs/v1/config`	The assembled project config — steps, texts, theme. Sends an ETag, so a cached copy costs a 304.
`GET /api/gs/v1/state`	Progress for one subject: completed steps, the next step, percentage.
`POST /api/gs/v1/complete`	Mark a step done. `dismiss` and `reset` sit beside it.
`POST /api/gs/v1/identify`	Attach a real user id to a visitor and merge their history.
`GET /api/gs/v1/stream`	Server-sent events for state changes, so a step completed in your backend moves the widget too.
`POST /api/gs/v1/server/complete`	The same completion, from your backend, with a secret key.

Where it runs

One binary with the database embedded. One SQLite file on a volume you control — no third-party script on your users' pages, no progress data leaving your infrastructure.

One process, one container, one file to back up.
GET /api/health and /api/health/ready for probes.
GET /metrics in Prometheus text format, with no extra agent.
Self-hosting is the only option, on purpose: your users' progress is your data.

Free while it is v1

There is no billing, no plan ladder and no quota to watch. Create an account, make as many projects as you need, and configure them freely. If that ever changes, existing projects keep working.

Create an account Read the bundle