Build a wedding RSVP form for your own website (no Google Forms)

Published 2026-07-14

Most wedding websites are static — a single page or a small static site built with a template, Squarespace-adjacent builder, or a static site generator. That's fine for the venue details and the photo gallery. It falls apart the moment you need an RSVP form, because a static site has nowhere to put the response.

The usual fallback is embedding a Google Form. It works, but it looks and feels like a Google Form dropped into the middle of your wedding site, and getting the data into something you can actually hand to a caterer means exporting a spreadsheet from a different product entirely.

This is a genuine use case for us — we've used SubmissionBuddy for a real wedding's RSVPs. Here's the same approach, written up as a how-to.

What the form needs to capture

A wedding RSVP form is short, but it has a few fields a generic contact form doesn't:

Guest name
Attending — yes/no
Meal choice (for the caterer's headcount by entree)
Plus-one name (optional, only relevant if attending)
Song request (optional, just for fun — DJs like having a list)

None of this needs a database schema. SubmissionBuddy's ingestion endpoint is schema-less — whatever fields you send are whatever fields get stored, so you can add a "dietary restrictions" field the week before the wedding without touching any configuration.

1. Get an endpoint

https://api.submissionbuddy.io/f/your-wedding-rsvp

A wedding's RSVP volume is usually well within the free plan — even a 150-guest wedding with separate RSVPs per household rarely clears a hundred submissions, and you only need the one form. If your guest list is large enough to need more, Pro raises that to 1,000 submissions/month.

2. The RSVP form

Drop this into your wedding website — plain HTML works on any static host:

<form action="https://api.submissionbuddy.io/f/your-wedding-rsvp" method="POST">
  <label>Your name
    <input type="text" name="guest_name" required />
  </label>

  <fieldset>
    <legend>Will you be attending?</legend>
    <label><input type="radio" name="attending" value="yes" required /> Joyfully accepts</label>
    <label><input type="radio" name="attending" value="no" required /> Regretfully declines</label>
  </fieldset>

  <label>Meal choice
    <select name="meal_choice">
      <option value="">— Select —</option>
      <option value="chicken">Chicken</option>
      <option value="beef">Beef</option>
      <option value="vegetarian">Vegetarian</option>
    </select>
  </label>

  <label>Plus-one name (if attending)
    <input type="text" name="plus_one_name" />
  </label>

  <label>Song request
    <input type="text" name="song_request" placeholder="What will get you on the dance floor?" />
  </label>

  <!-- hidden honeypot: bots fill it, real guests never see it -->
  <input type="text" name="_honeypot" style="display:none" tabindex="-1" autocomplete="off" />

  <!-- send guests to a thank-you page after they RSVP -->
  <input type="hidden" name="_redirect" value="https://your-wedding-site.com/thank-you/" />

  <button type="submit">Send RSVP</button>
</form>

That's the whole integration — no backend to write, no spreadsheet to wire up. Field names are entirely up to you; there's no schema to configure ahead of time.

A few things worth calling out:

The _redirect field sends guests to a proper thank-you page after they submit, instead of leaving them staring at a blank success message. It works on every plan, including Free.
The _honeypot field is a hidden input real guests never see or fill in. A bot that fills in every field on the page fills this one too — SubmissionBuddy silently drops that submission (no email, no dashboard entry) while still returning a normal-looking success response, so the bot never learns it was caught.
Both _redirect and _honeypot are stripped out before your data is stored — they're control fields, not part of the RSVP record.

3. What happens after a guest hits submit

The submission is written to durable storage, then flows through to two places:

Email — a notification lands in your inbox (or whoever you've configured as the recipient) for every RSVP, so you see them as they come in without needing to check a dashboard.
Dashboard — the same RSVP is searchable and filterable in the SubmissionBuddy dashboard: search by guest name, filter by date, sort by any field including attending or meal_choice.

4. Turning RSVPs into a headcount for the caterer

This is where a dedicated form backend earns its keep over a pile of forwarded emails. From the dashboard, export everything to Excel (.xlsx) — one click, no third-party tool. Sort by meal_choice before exporting and you have your caterer's entree breakdown; sort by attending and you have your final headcount. It's the same export you'd hand off for a seating chart, just built from the fields you already collected.

Prefer JavaScript? Use fetch

If you'd rather stay on the page and show an inline "thanks for RSVPing" message instead of redirecting:

const res = await fetch('https://api.submissionbuddy.io/f/your-wedding-rsvp', {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    guest_name: form.guest_name.value,
    attending: form.attending.value,
    meal_choice: form.meal_choice.value,
    plus_one_name: form.plus_one_name.value,
    song_request: form.song_request.value,
  }),
})

if (res.ok) {
  // 202 { "ok": true, "submission_id": "…" }
  showThankYouMessage()
}

JSON, application/x-www-form-urlencoded, and multipart text fields are all accepted, so this works whether your wedding site is a hand-written HTML page or built with a static site generator.

That's the whole thing

No Google Forms embed, no spreadsheet export from a different product, no backend to build for a form you'll use once. Point the form at the endpoint, add the honeypot and redirect fields, and RSVPs start landing in your inbox and your dashboard the same day.

Get your free endpoint — 100 submissions/month across up to 2 forms, no credit card required.