---
title: "Event sign-ups fanned out to your services"
description: "Post each RSVP as JSON to one endpoint that writes the attendee row and publishes a message the rest of your services subscribe to, not the form."
url: "https://www.formformform.com/automations/webhooks-signups-to-attendee-service"
type: static
generatedAt: "2026-08-23T18:56:58.727Z"
---
![Webhooks logo](/logos/integrations/webhooks.svg)

# Fan event sign-ups out to your own services

One POST per RSVP writes the attendee to your database and publishes a message the rest of your services can listen for.

When this happens

New submission on your event registration form

Do this

POST the registrant JSON to an endpoint that writes to your attendee database and publishes a message to your internal event bus

One-directional. A submission triggers the action — nothing is written back into your form.

An events team running its own tooling has more than one thing to do with an RSVP: record the attendee, count the catering, tell the badge printer, send a confirmation. Doing that through four separate integrations means four places to fix when the form changes.

One webhook is easier to reason about. The endpoint writes the attendee row, then publishes a message on your internal bus, and every downstream service subscribes to that rather than to the form. Adding a service later needs no change to the form at all.

## Setting it up

1.  1
    
    Publish the registration form and keep Ticket Type a select whose option names match the ticket classes your attendee database already uses.
    
2.  2
    
    Add a POST route — /webhooks/rsvp — that accepts JSON, and settle now that it writes the row before it publishes anything.
    
3.  3
    
    Enable the outgoing webhook in the form's settings, paste the route URL, and save the form.
    
4.  4
    
    Send one test RSVP and log the body, checking the keys for Ticket Type, Number of Additional Guests and Dietary Restrictions.
    
5.  5
    
    Insert the attendee row in a transaction keyed on Email Address, so a re-submitted RSVP updates the booking rather than adding a second seat.
    
6.  6
    
    Cast Number of Additional Guests to an integer and add it to the head count in the same transaction, so catering numbers never drift from the attendee table.
    
7.  7
    
    Publish an attendee.registered message after the commit, carrying the attendee id rather than the whole payload, so subscribers read a row they can trust.
    
8.  8
    
    Return 2xx only once the publish is acknowledged; a non-2xx tells you the RSVP needs replaying instead of leaving a silent gap in the list.
    

## What maps where

Using the [Event Registration Form](https://www.formformform.com/templates/event-registration-form) as the starting point. These are its real fields — swap in your own and the mapping works the same way.

Form field

Webhooks

Full Name

attendee name on the new row

Email Address

unique key on the attendee table

Ticket Type

ticket class on the attendee row

Number of Additional Guests

head count, added in the same transaction

Dietary Restrictions

catering field on the attendee row

Accessibility Requirements

accessibility note passed to the venue

## Variations worth knowing

Publish one message per downstream job

Instead of a single attendee.registered event, emit catering.updated and badge.requested from the same handler. Subscribers stay narrow, and a failure in badge printing does not retry the catering count. It costs you more topics, and it earns its keep once more than two services care about an RSVP.

Keep accessibility notes off the general bus

Accessibility Requirements and Dietary Restrictions describe a person, not a booking. Write them to the attendee row and give the venue a scoped read rather than broadcasting them to every subscriber. The published message carries the attendee id, so a service that genuinely needs them can ask.

## If something isn't arriving

Head counts are higher than the number of attendees.

Number of Additional Guests is being added on every delivery, repeats included. Make the write idempotent — key it on the submission id, or on Email Address with an update on conflict — because nothing is written back to the form to mark an RSVP as already counted.

Downstream services act on an attendee that does not exist yet.

The message is published before the transaction commits, so a subscriber reads the row a moment too early. Publish after the commit, or write to an outbox table inside the same transaction and let a poller drain it, which keeps the row and the message in step.

## Frequently asked questions

Can attendees change their RSVP later?

They can submit the form again, and your handler decides what that means. Keying the attendee row on Email Address with an update on conflict turns a second RSVP into an edit. Nothing is written back into the form, so their earlier answers are not shown to them.

Why publish a message instead of calling each service from the handler?

Calling them directly makes the RSVP handler responsible for every downstream failure, and the delivery status starts reflecting whether your badge printer is awake. A message keeps the handler's job small: write the row, announce it, return 2xx.

Do I need a separate webhook for each event I run?

Only if each event has its own form. One form per event gives each its own webhook URL and keeps the attendee tables apart. A single form works too — add a question naming the event and route on that answer inside the handler.

## Related automations

-   [Deliver job applications to your hiring service](https://www.formformform.com/automations/webhooks-applications-to-hiring-service)
    
    Every application is posted as JSON to your applicant tracking service, which validates the fields before it creates a candidate.
    
-   [Push support requests onto your own job queue](https://www.formformform.com/automations/webhooks-support-tickets-to-queue)
    
    Every support submission is posted to an endpoint that enqueues the request and sets its priority from the answer on the form.
    
-   [Send custom orders to your fulfilment backend](https://www.formformform.com/automations/webhooks-orders-to-fulfilment-api)
    
    Each order submission is posted to your orders API, which records the items and starts fulfilment with nothing rekeyed by hand.
    
-   [Stream feedback scores into your analytics pipeline](https://www.formformform.com/automations/webhooks-feedback-into-your-warehouse)
    
    Each NPS response is posted to an ingestion endpoint that normalises the score and streams the record into your warehouse.
    
-   [Write new leads straight into your own database](https://www.formformform.com/automations/webhooks-leads-to-your-database)
    
    Each lead capture submission reaches your endpoint as JSON and becomes a row in your own leads table, seconds after it is sent.
    
-   [Add every RSVP to your confirmed guest list](https://www.formformform.com/automations/trello-rsvps-to-guest-list)
    
    Each RSVP creates a card on the "Confirmed guests" list with the ticket type as a label and dietary notes in the description.
    

-   [All Webhooks integration details →](https://www.formformform.com/integrations/webhooks)
-   [Start from the Event Registration Form →](https://www.formformform.com/templates/event-registration-form)
-   [Browse every automation →](https://www.formformform.com/automations)

## Build the form first

The automation needs somewhere to fire from. Publish a form, connect it once, and every submission from then on runs this flow.

[Start free](https://app.formformform.com/register?utm_source=landing&utm_medium=bottom&utm_campaign=automations&utm_content=webhooks-signups-to-attendee-service)