Connect an event to your own CRM and Quick Event keeps it fed: not only the first registration, but every later correction and every check-in scan. You enter an HTTPS address under Registration › CRM, and Quick Event posts signed JSON to it.
A CRM that only ever learns about the first contact is out of date from the first correction onward. That is why changes and scans are part of the stream, not an extra you have to build.
One-way, on purpose
Data only ever leaves Quick Event. Nothing can be written in from outside. There is no inbound key, no public write endpoint, and no way for a connected system to create or change a booking.
That is a deliberate decision, not a missing feature. An inbound write path would need its own permission model, its own duplicate handling and its own transaction boundary around the booking logic — every one of those is a way to corrupt a live event's guest list from the outside. Outbound only has none of that surface.
What you do with the data on the other side is entirely yours: a CRM, a data warehouse, a spreadsheet, or an automation flow that fans it out to several of them.
What is sent
Each delivery is a JSON body with a records array. Every record names its kind and its op, so a receiver can upsert on a stable ID rather than guess.
| Kind | Sent when | Contains |
|---|---|---|
participant | Someone registers, or their data is corrected later | The answers to your registration form, keyed by field ID |
booking | A booking is created or its payment status changes | Ticket names, quantities, total, payment status |
checkin | A badge is scanned at the entrance | Check-in point name, direction, device, whether it was an override |
Deletions arrive as { "kind": …, "op": "delete", "id": … } — no reload needed on your side. Alongside records, every body carries a fields block: the ID, label, type and required flag of each registration form field. Your form is free-form, so without that legend a receiver would see field IDs and no way to map them to labels.
How delivery works
- At least once. Every record carries a stable ID; upsert on it and a repeat is harmless. Exactly-once would require a two-phase acknowledgement from your side — stable IDs are the cheaper and more common contract.
- Roughly once a minute. Changes are collected in an outbox and delivered in batches, up to 100 records per request.
- Order is kept per destination. Each destination has its own cursor, so a broken endpoint never blocks a healthy one — and never silently skips the records it missed while it was down.
- Failures are visible. The destination row shows when it last delivered and what the last error was. After 20 consecutive failures the destination is switched off, with the reason still on screen — it does not fail quietly forever.
- Ten second timeout, three redirects. Answer with any 2xx status; the body is ignored.
Signature and safety
Every request carries two headers:
x-quickevent-timestamp— Unix secondsx-quickevent-signature—sha256=<hex>, an HMAC-SHA256 over<timestamp>.<body>using your destination secret
Recompute it on your side and compare in constant time; reject anything whose timestamp is far from now. The secret is generated when you create the destination and shown exactly once — Quick Event stores only what it needs to sign, so a leaked secret is replaced by creating a new destination, never recovered.
Destination URLs must be HTTPS, may not carry credentials, and are checked against private and link-local address ranges — both when you enter them and again at the moment the connection is made, on every redirect hop. That second check is the one that matters: a first lookup returning a public address and a second returning a loopback one is the classic rebinding attack, and a single up-front validation walks straight past it.
Setting it up
- Open Registration › CRM in the event.
- Add a destination: a name, the HTTPS URL, and which kinds it should receive — participants, bookings, check-ins, or any combination.
- Copy the secret. It is shown once.
- Press Test. Quick Event sends a signed request straight away and shows the status it got back, so a typo in the URL surfaces before the first real registration.
You can add several destinations per event — a CRM and an n8n flow side by side is the normal case, not an edge case. Each has its own secret, its own filter and its own delivery state. Switch one off and it stops immediately; the others are untouched.