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.
New submission on your event registration form
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
Publish the registration form and keep Ticket Type a select whose option names match the ticket classes your attendee database already uses.
- 2
Add a POST route — /webhooks/rsvp — that accepts JSON, and settle now that it writes the row before it publishes anything.
- 3
Enable the outgoing webhook in the form's settings, paste the route URL, and save the form.
- 4
Send one test RSVP and log the body, checking the keys for Ticket Type, Number of Additional Guests and Dietary Restrictions.
- 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
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
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
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 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
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.
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
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.
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
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
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
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
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
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
Each RSVP creates a card on the "Confirmed guests" list with the ticket type as a label and dietary notes in the description.
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