How SPARK fits your launch

Your public waitlist link

Every app gets a simple address you can post on social, in a deck, or in a DM. It is the path /app/your-name on your SPARK site—the middle part (the slug) is what you choose under Dashboard → Branding → Overview.

What it looks like

https://spark.nomadis.com/app/your-slug

Visitors leave an email; you see them in Dashboard → Overview and can explore trends in Analytics. No spreadsheets to babysit for the first wave of interest.

Use your own domain

Owning myproduct.com and sending people straight to SPARK is a common flex. The reliable pattern is a redirect at the company where you bought the domain (sometimes called URL forwarding or web redirect): visitors type your domain, and they land on your full waitlist URL.

Why not only point DNS with a CNAME? That path often breaks the browser padlock unless the service issues a certificate for your hostname. A redirect keeps encryption simple—your domain hands off to SPARK’s HTTPS URL in one clean step.

1. Open your registrar’s redirect or forwarding tool and send traffic to your real waitlist address, for example https://spark.nomadis.com/app/your-slug (swap in your slug).
2. Use a permanent redirect when you are sure; use a temporary one while you are still experimenting.
3. If you want both www and the bare domain to work, set the redirect for each.

Put the waitlist on your website

Keep your marketing site where it is and still show the exact same SPARK signup with an embed (a small frame that loads your waitlist page inside your layout). Copy the snippet from Dashboard → Branding → Widget and paste it into Webflow, Framer, Notion public pages, or plain HTML.

Treat the embed like a mini page: give it enough height and width so the form does not feel cramped or scroll twice. Always use https when you are live. Point the iframe at the same waitlist URL people would open in a new tab so the experience, links, and signups stay in sync.

Outbound webhooks

What is a webhook? Think of it as SPARK tapping your automation on the shoulder the moment something happens. Instead of you polling “any new signups?”, SPARK sends a single structured message to a URL you choose—like a doorbell for your stack. Popular tools (Zapier, Make, n8n, or a short script on Railway) can listen for that knock and fan out to Slack, a database, a welcome sequence, or a Notion row.

Why people use them. You keep SPARK as the friendly face for subscribers while your other systems stay in sync—no manual CSV exports for every experiment. It is optional: if you never add a webhook, nothing changes; your dashboard still collects everyone.

Turn it on under Dashboard → Webhooks. Point SPARK at an https address that accepts a quick POST and answers fast—any success-style response in the 200 range tells us “got it.” If something else comes back, we treat it as a miss and note it for you so you can fix the other end.

Event name you will see

waitlist.subscriber.created

Example payload (shape)

{
  "event": "waitlist.subscriber.created",
  "app_id": "<uuid>",
  "subscriber": {
    "id": "<id>",
    "app_id": "<uuid>",
    "email": "user@example.com",
    "created_at": "2026-03-29T12:00:00Z"
  }
}

Extra fields on subscriber (where someone came from, campaign tags, and similar) only appear when they exist—empty values are left out so the payload stays tidy.

Trying it on your laptop. The dashboard can call http://localhost webhook URLs while you iterate. SPARK also ships a tiny echo endpoint at POST /webhooks that replies with JSON so you can confirm deliveries before your real automation is ready.

Back to home · About