Data Integration
Connect an event to Luma, Eventbrite, Cvent, Swoogo, Bizzabo, Salesforce or any system with an API or a webhook — pull records in, optionally push attendees out, and decide with rules and conditions what crosses over.
The gist
- Registration lives on another platform; the badge, the app and the door scanner live here. This closes the gap without anybody exporting a CSV every morning.
- Records land in a buffer first — exactly as the other platform sent them — and are only then translated and written. That is what makes a wrong mapping fixable: correct the rule and replay the same records.
- Confirmation emails are off by default. The first sync backfills everyone who already registered, sometimes months ago. Turn it on only once the backfill is done.
- Pushing out is a separate switch, also off by default. Sending your attendees to a CRM writes into somebody else's system, which nothing here can undo — so it never starts just because a connection was switched on.
What it is
A connection to another platform, plus the rules that turn their record into yours. Records come in two ways at once: a webhook brings each registration across within seconds, and a scheduled pull re-reads the whole guest list as a backstop. Where the platform allows it, a push sends your attendees the other way. Every platform is set up the same way — the Custom API / webhook connector covers any system that is not in the list.
When to use it
Any event that sells or collects registrations somewhere else. It replaces the export-and-upload loop, and — unlike an upload — it keeps working while nobody is watching.
Before you start
- An API key from the other platform, and their event's ID.
- Your attendee fields set up, if you want their custom questions to land on real fields rather than in a metadata bag. Read the guide
Try it — this is a sandbox, nothing here is real
Connect a Luma event whose guest list has a gender field written as M and F. Take the shortcut first if you want to see what an unchecked mapping costs.
A Luma connection, named but not yet proved.
Credentials
A new connection always starts paused. Nothing is fetched, and webhook deliveries are refused, until you switch it on.
1,840 confirmation emails sent
Added 1,840 · updated 0 · emailed 1,840
The first sync is not a stream of new registrations — it is everyone who has ever registered, some of them months ago. They get a welcome from a brand they did not sign up with, and the replies come to you.
This is why Send the confirmation email is off unless you turn it on. Leave it off for the backfill; turn it on afterwards for the live feed.
1,840
Fetched
1,840
In the buffer
0
Written
The buffer now holds what Luma actually sent. That is what the mapping preview reads from — and what a replay goes back to when a rule turns out to be wrong.
Required
On
Copies as-is
What the last record would become
email [email protected] · first_name Ada · gender M
Everyone's gender says M or F
The sync reported success. Nothing failed — the value was copied exactly as Luma sent it.
A mapping with no converter copies, and copying is usually right. It is only wrong when the two systems spell the same fact differently, and nothing but a human reading the preview can tell the difference.
Nothing is lost. The raw records are still in the buffer, so adding the conversion and replaying corrects the attendees that were already created.
Clean it up
Trim whitespace → Uppercase
Convert the value
M → Male · F → Female
What the last record would become
email [email protected] · first_name Ada · gender Female
31 records need attention
“Prefer not to say” is not one of the values this field converts.
Failing on an unlisted value is the right setting when an unrecognised value means the other platform changed something. It is the wrong one for a free-text answer, where it parks real people over a spelling.
1,836
Applied
4
Need attention
applied
failed
Expanding a row shows what Luma sent beside what our rules made of it. That is how you find out whose field changed.
Active
Webhook receiving · pull every 15 minutes · confirmation emails on
The webhook carries a registration within seconds. The pull re-reads the whole guest list and catches whatever the webhook dropped while something was restarting. Records we already hold are recognised and discarded, so the pull is cheap.
Which attendees are sent
Required
Required
On
Only what a rule names is sent. Nothing else about an attendee leaves — an unmapped field stays here.
1,836 records written to Salesforce
Checked 1,836 · sent 1,836 (1,836 new, 0 updated)
With no condition, every attendee is sent — including the four hundred who registered and never came. And with nothing to match on, a first push can only create, so everyone the CRM already held now exists twice.
Nothing on this side can undo a write to somebody else's system. That is why push is its own switch, off by default, and why a dry run shows “would create” against “would update” before anything is sent.
1,836
Checked
1,412
Sent
0
Need attention
From here it runs on the connection's schedule, and it only re-sends an attendee when one of the fields you send has actually changed — so pulling from and pushing to the same platform does not go round in circles.
Click a control above. One of them is the mistake people actually make — take it on purpose.
Step by step
- 1
Open the console/admin/[eventId]/integrations
Data Integration is not in the dashboard menu — it is not released yet, so it is reached by its address. That page hands you a signed link to the console, which lasts eight hours; come back to it for a fresh one rather than bookmarking the console.
Tip. It is a separate deployment on purpose: it holds another company's API keys, so it deliberately carries as few of ours as possible.
- 2
Add a connection and install the key
Pick the platform, name the connection, then paste the API key and their event ID. The key is encrypted at rest and never shown again — the field afterwards displays only the last four characters, so you can confirm which key is installed without it being readable. Platforms marked Beta were built from the platform's published API and have not yet been proved against a live account: test the connection and do a dry run before relying on one.
Tip. Press Test connection before anything else — it is at the top of the connection, on every tab, beside Sync now and Process buffer. A wrong event ID otherwise shows up as an empty guest list at 3am rather than as an error in front of you. The short checklist under the connection's name shows which step comes next, and disappears once the connection is working.
- 3
Check the field mapping
Each rule takes one of their fields and writes one of yours. The defaults cover name, email and ticket type. The preview underneath runs the real converters against the most recent record that actually arrived, so what you see is what the next sync will write.
Careful. Run a dry run first if nothing has arrived yet — the preview has nothing to work with until a record is in the buffer.
- 4
Convert the values that mean the same thing
Open Converters on a rule. The first half cleans the value up — trim it, lowercase it, take the first word of a full name, parse their date format. The second half is the business rule: a table saying their `M` becomes our `Male`.
Tip. Cleaning runs before converting, so a table written as
M → Malestill matches a payload that sends" m ". - 5
Add the “if”: conditions
At the top of the mapping, Which records come across is a filter: add
guest.approval_status is approvedand anything else is skipped, with the reason shown on its row in the buffer. On a single rule, open Conditions & converters and use Only when to make that rule apply to some records only. Add a Set a fixed value step to write a value of your own — *when the ticket contains VIP, attendee type is delegate*.Tip. Rules run top to bottom and the later one wins. Put the general rule first and the exception under it, and you have an if / else.
- 6
Decide what happens to each record
The two that matter most: Send the confirmation email (off by default) and Process records as they arrive (turn it *off* while a new mapping is being proved, so the buffer fills and waits for you).
Careful. A first sync is a backfill. Emailing everyone on it sends a welcome from a brand they did not register with, to an address they used months ago.
- 7
Sync, then read the buffer
Sync now fetches, buffers and processes. Then open Buffer and filter to *Need attention* for records that need a correction. Expanding one shows exactly what arrived beside exactly what we made of it. Temporary service errors, rate limits and conflicting edits leave records pending for the next processing run; they do not need Replay all failures. Older records at the bottom pages back through the buffer.
- 8
Fix the mapping and replay
Correct the rule, save, and press Replay all failures — or Replay on a single row to try just that one. Then press Process buffer. The same records go through the new mapping — nobody has to ask the other platform to send them again, which for a webhook they never will.
Tip. The Save button stays at the bottom of the screen and says when there are unsaved changes. Leaving the page with some asks you first.
- 9
Switch it on for the event
Turn on Active, turn on both the webhook and the scheduled pull, and paste the webhook address into the other platform. Then set the Webhook secret: paste the signing secret the other platform shows you, or — if it lets you choose one — make up a long random value and enter it in both places. Neither mechanism is reliable alone; together they converge.
Careful. A delivery that does not carry the right secret is refused. The address alone is never enough.
- 10
Optionally, push attendees out
On a platform that supports it (Salesforce, or a custom address), open Field mapping → Going out and say which of your fields land in which of theirs. Add a condition under Which attendees are sent —
checked_in is truesends only the people who came. Then switch on Push attendees to this platform, turn on Dry run, and press Push now: the buffer shows what would be sent, and whether each person would be created or updated, without sending anything.Tip. An attendee is only sent again when one of the fields you send has changed, so pulling from and pushing to the same platform does not loop. Large scans can span several runs: the next push resumes where the previous scan stopped, including when many attendees changed at the same time.
Careful. Only what a rule names is sent. But what is sent cannot be recalled from here, so read the dry run before the real one.
When it goes wrong
Every one of these has happened to someone. Symptom first, because that is what you will have.
The first sync emailed everybodyblocker
Everyone's gender says Mwarning
M → Male), save, then Replay — filter the buffer to *Applied*, replay them, and process. The same records go through again and correct the attendees they created.Records fail with “No email address in this record”blocker
“is not a date we can read”warning
31/12/2026 instead of an ISO timestamp is the usual one.The webhook address is saved but nothing arrivesgotcha
The first push wrote everybody, some of them twiceblocker
The other platform's delivery log shows 401sgotcha
x-webhook-secret header.“That address is not reachable from here”gotcha
https://, or it points at a private or internal network. Those are refused on purpose.https:// address. A system that is only reachable inside your network cannot be pulled from or pushed to; have it send a webhook to us instead.Somebody appears twicegotcha
“This link has expired”gotcha
/admin/[eventId]/integrations) again for a fresh one. It has no menu row while the feature is unreleased.What people ask
Kept in the words people use, because that is what you are about to type.
Where do their custom registration questions go?
Anywhere you point them. Map one to an attendee field you defined under Attendee Fields and it behaves like any other field. Anything you have not mapped is kept on the attendee record under a prefix, so you can see what else they send and map it properly later.
Does this ever delete attendees?
No. A sync creates and updates; it never removes — in either direction. Deleting the connection itself also leaves every attendee it created in place, and deleting an attendee here does not delete anything on the other platform.
How are API keys stored?
Encrypted (AES-256-GCM) before they reach the database, with the encryption key held outside it — so a copy of the database alone cannot be used to read them. They are never sent to your browser: after saving, the field shows only the last four characters. The same applies to a webhook secret, and to the short-lived access tokens some platforms issue, which are kept in memory only and never stored.
My platform is not in the list. Can I still connect it?
Usually, with Custom API / webhook. Give it an https:// address that returns JSON and say where the records are in the response; or have your system send a webhook; or have us send each attendee to an address of yours. The mapping, conditions, buffer and replay all work the same way.
What exactly is sent when I push?
Only the fields your outbound mapping names, for the attendees your condition allows. Unlike the incoming side there is no “keep the unmapped fields” option — anything you have not mapped stays here.
Can I see what the other platform actually sent?
Yes — that is what the buffer is for. Expand any record to see the raw payload beside what our rules made of it.
How often does the scheduled pull run?
As often as you set, down to every five minutes. Below that the platforms rate-limit the key, which would slow every other connection on the same account.
Is a full pull expensive if nothing changed?
No. Records we already hold are recognised and discarded, so an unchanged guest list costs a few requests and writes nothing.