← Blog

How to add a waitlist to a static website without a custom API

Add a static-site waitlist with one hosted form endpoint — no custom API, optional source metadata, spam controls, and export when you launch.

To add a waitlist to a static website, use a plain HTML form that posts to a hosted signup endpoint. Keep the site static, collect only the email unless you need more, and export the list when launch day arrives.

A launch landing page on Cloudflare Pages, Netlify, GitHub Pages, or object storage is mostly HTML and assets. The awkward bit is the waitlist: you need somewhere durable for emails without standing up an API, a database, or a form backend on that host.

Why waitlists feel hard on static hosts

Static hosts serve files. They do not run your preferred server framework on every request. Pointing action at a relative PHP or Node path fails; stuffing addresses into a spreadsheet by hand does not survive a real launch spike. You want a thin intake layer: accept email, reject junk, export later.

Minimum viable waitlist

  • Email — the only required field for most launches.
  • Optional source metadata — e.g. landing, hero, or a ref code so you know which page or campaign drove the signup.
  • Spam controls — launch posts and Product Hunt days attract bots as well as humans.
  • Export — CSV/JSON when invites or double opt-in confirmation go out.

Spam and launch-spike concerns

A public form on a loud launch will see more traffic than a quiet beta. Prefer a domain-locked endpoint, rate limits, a honeypot, and optional bot challenge rather than trusting the static host alone. Field-level detail lives in the developer docs; this post stays at the pattern level.

Simple Signups approach

Create one campaign per waitlist, allow-list the domains that embed the form, and POST to the subscribe endpoint. No SDK. For the product-shaped guide (copy tone, worked blurb, dashboard habits), use the canonical waitlists use case— this article is the SEO how-to; that page is the worked product flow.

Working HTML example

Single email field, honeypot empty, swap in your public campaign id (pub_...). Full field reference: quickstart.

HTML waitlist form
<form action="https://simple-signups.com/api/subscribe" method="POST">
  <input type="hidden" name="campaignId" value="pub_your_campaign_id" />
  <input type="email" name="email" required placeholder="you@example.com" />
  <input type="text" name="hp" tabindex="-1" autocomplete="off"
    style="position:absolute;left:-9999px" aria-hidden="true" />
  <button type="submit">Join waitlist</button>
</form>

After submit: tell people what happens next

Even a one-field waitlist needs a clear next step. Show an inline success state or a small thank-you page that tells people whether they should expect launch updates, invites, or a confirmation email. The page should not leave them guessing whether the submit worked.

Optional tags + metadata (source / ref)

Tag the contact (e.g. waitlist) for filtering/export, and attach a small metadata object when you need free-form attribution without extra visible inputs. Caps and types are documented under tags and metadata & extra fields.

fetch with tags + metadata
await fetch('https://simple-signups.com/api/subscribe', {
  method: 'POST',
  headers: { 'content-type': 'application/json' },
  body: JSON.stringify({
    campaignId: 'pub_your_campaign_id',
    email: 'jane@example.com',
    tags: ['waitlist'],
    metadata: { source: 'landing', ref: 'hero' },
  }),
});

When source tracking is worth it

Keep day-one waitlists minimal. Add metadata only when multiple landing pages, ads, or partners point at the same list and you need to know which source produced the signup. If not, email alone is usually enough signal for an early launch.

When you leave waitlist mode

When you are ready to move beyond a simple launch list, export confirmed (or pending) subscribers from the dashboard to CSV or JSON, or forward submissions into the rest of your stack with webhooks. Simple Signups can stay as the intake layer in front of your ESP or CRM rather than forcing you to choose between a static-site form and the tools you already use later.

Related