WhatsApp for Conference and Event Organizers — Check-in, Schedule Changes, and Follow-ups

A multi-day conference generates a steady stream of updates that attendees need fast: a confirmed registration, an e-ticket to show at the door, a room change twenty minutes before a session, a weather-driven schedule shift. Email is the default channel for most ticketing platforms, but open rates on event-day emails are poor — attendees are walking around a venue, not checking their inbox. WhatsApp reaches the same phone they're already holding, with message threads they can scroll back through to find "which room was that talk in again?" without digging through a folder of event emails.

This is a different use case from wedding and private-event coordination, where the volume is lower and the messages are mostly RSVP-driven — see our guide on WhatsApp for wedding and event planners if that's closer to your situation. A conference runs at higher volume, often hundreds or thousands of attendees, over a short and intense window.

The message types a conference actually sends

• Registration confirmation — sent the moment a ticket purchase or free registration completes, confirming the event, date, and venue.
• E-ticket or badge QR code — a media message with the scannable code attendees show at check-in, sent a day or two before the event so it's easy to find.
• Schedule change alerts — a room swap, a delayed start, a speaker substitution. These are time-sensitive and need to land in minutes, not the next email digest.
• Day-of reminders — a morning message with the day's agenda highlights and any last logistics (parking, badge pickup desk).
• No-show follow-up — sent after the event to registered attendees who never checked in, with a recording link or a note about the next edition.

Only the first and last of these are one-off; schedule changes and day-of reminders are the moments where a fast channel earns its place over email.

Sending the e-ticket as media

Badge QR codes and e-tickets are images or PDFs, not text, so this flow depends on media sends rather than plain messages:

curl -X POST https://api.textmeflow.eu/v1/messages \
  -H "Authorization: Bearer $TEXTMEFLOW_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "to": "+32470123456",
    "text": "Your badge for DevConf 2026 — show this at check-in, doors open 08:00.",
    "media_url": "https://tickets.example.com/qr/abc123.png"
  }'

Media sends up to 100 MB are supported, which comfortably covers a PDF ticket or a high-resolution QR code — see the media documentation for the supported formats and size limits.

Wiring it to your ticketing platform

Most ticketing tools (Eventbrite, Tito, a custom registration form) can fire a webhook on purchase or trigger an automation in n8n, Make, or Zapier. The pattern is the same one used for any transactional trigger:

1. The ticketing platform posts a "registration complete" event to your automation layer.
2. The automation maps the attendee's phone number and ticket details into a message, pulling the QR code or PDF URL generated by the ticketing platform.
3. The automation calls the textmeflow API to send it.

For schedule changes, the trigger is usually manual — an organizer updates the agenda tool and a short script pushes the change to everyone registered for that session, rather than the whole attendee list. Keeping schedule-change blasts scoped to the affected session, instead of broadcasting to every attendee for every small update, keeps the channel useful instead of noisy.

Timing matters more than volume here

A room change sent at 2 a.m. the night before a 9 a.m. session is useless if nobody reads it before arriving. If you're queuing day-of reminders or schedule pushes ahead of time, make sure they land during the hours attendees are actually awake and checking their phone — our guide on quiet hours and deferred sends covers how textmeflow handles that automatically, so a message queued at midnight doesn't fire until morning.

What to keep in mind

• These are transactional messages tied to an existing registration, not marketing broadcasts — but only message the number the attendee provided at registration, and stop immediately on a STOP request. textmeflow's anti-spam pipeline enforces STOP handling automatically.
• Replies come back as webhooks. An attendee asking "where's the parking entrance?" lands as an inbound event your team can route to whoever is staffing the help desk that day — see the webhooks documentation for the event payloads.
• Keep broadcasts scoped. A full-attendee-list send for every update erodes attention fast; scope messages to the session, track, or ticket type actually affected.

Getting started

Start with the two highest-value messages: the e-ticket send and same-day schedule-change alerts. That alone replaces the two things attendees complain about most at in-person events — losing their ticket and missing a room change. Sign up free and send your first confirmation before your next event.