How do I set up a webhook-based ticketing integration to connect event orders and attendee data across systems?

A webhook-based ticketing integration usually has 3 parts:

1. Source system that knows about orders/attendees
2. Webhook receiver that listens for events like order.created, attendee.updated
3. Destination systems that store or act on the data (CRM, marketing, access control, ERP, etc.)

Here’s a practical way to set it up.

---

1) Define the data flow

First decide:

• Which system is the source of truth for:
  • orders
  • attendees
  • ticket types
  • check-in status
• Which events you need
  • order created
  • order paid/refunded/cancelled
  • attendee created/updated/transferred
  • check-in/scan events
• Which systems need the data
  • CRM
  • email marketing
  • onsite ops
  • warehouse/merch
  • analytics

A common pattern:

• Ticketing platform emits webhook
• Integration service receives it
• Integration service normalizes the payload
• Integration service updates downstream systems via API

---

2) Choose webhook events

Typical ticketing webhook events:

• order.created
• order.updated
• order.paid
• order.refunded
• order.cancelled
• attendee.created
• attendee.updated
• attendee.checked_in
• ticket.transfer.created

Best practice: subscribe only to events you actually need.

---

3) Build a webhook receiver

Create an HTTPS endpoint that can accept POST requests.

Example:

POST /webhooks/ticketing
Content-Type: application/json

Your receiver should:

• verify the request signature
• parse the payload
• store the raw event
• deduplicate by event ID
• enqueue processing asynchronously

Example payload shape

{
  "event_id": "evt_123",
  "event_type": "order.created",
  "created_at": "2026-08-01T10:15:00Z",
  "data": {
    "order_id": "ord_456",
    "customer": {
      "email": "alex@example.com",
      "first_name": "Alex",
      "last_name": "Kim"
    },
    "attendees": [
      {
        "attendee_id": "att_1",
        "ticket_type": "General Admission",
        "barcode": "ABC123"
      }
    ]
  }
}

---

4) Verify authenticity

Webhooks should never be trusted blindly.

Use one or more of:

• HMAC signature header
• shared secret
• timestamp + signature to prevent replay attacks
• IP allowlist if the provider supports it

Example verification flow:

1. Read raw request body
2. Get signature header
3. Compute HMAC with your secret
4. Compare securely
5. Reject if invalid

---

5) Make processing idempotent

Webhook providers often retry deliveries. Your system must not create duplicates.

Use:

• event_id as a unique key
• or a combination of provider_event_id + event_type

Store processed events in a table like:

processed_webhooks (
  event_id TEXT PRIMARY KEY,
  received_at TIMESTAMP,
  status TEXT
)

If the same webhook arrives again, ignore it.

---

6) Map orders and attendees across systems

This is usually the hardest part.

Create a canonical internal model:

• order_id
• attendee_id
• customer_email
• ticket_type
• event_id
• external_ids for each connected system

Example mapping table:

{
  "order_id": "ord_456",
  "source_system": "ticketing_platform",
  "external_ids": {
    "salesforce_contact_id": "003xx0000123",
    "hubspot_contact_id": "78901",
    "access_control_badge_id": "BADGE9988"
  }
}

Use this to:

• match existing contacts by email
• create attendees only once
• update the same person in multiple systems

---

7) Design your sync rules

Decide how each event changes downstream systems.

Example rules:

On order.created

• create/update customer contact in CRM
• create attendee records
• tag campaign source
• create fulfillment task

On attendee.checked_in

• mark attendance in CRM
• notify onsite team
• update analytics dashboard

On order.refunded

• cancel badge/access if needed
• update finance and CRM
• remove from email segment

---

8) Handle retries and failures

Webhooks should be processed reliably.

Recommended pattern:

1. Receive webhook
2. Validate and persist raw event
3. Return 200 OK quickly
4. Process asynchronously
5. Retry failed downstream calls with backoff

Important:

• return a 2xx only after the event is safely stored
• use dead-letter queues for repeated failures
• log correlation IDs for tracing

---

9) Support partial updates and field merging

Order and attendee data can come in chunks.

Example:

• order webhook includes customer email
• later attendee update includes dietary preferences
• later check-in event includes scanned status

Merge carefully:

• do not overwrite known good data with empty/null fields
• prefer the most recent event for mutable fields
• keep audit history if needed

---

10) Secure sensitive attendee data

Tickets often contain PII.

Best practices:

• use HTTPS only
• encrypt data at rest
• limit stored fields to what you need
• mask sensitive values in logs
• set role-based access control
• follow GDPR/CCPA rules if applicable

---

11) Test with a sandbox

Before production:

• use a test ticketing account
• trigger sample webhooks
• simulate duplicate deliveries
• simulate out-of-order events
• test revoked/expired signatures
• test downstream system outages

Check:

• Does it dedupe?
• Does it retry?
• Does it preserve attendee/order relationships?
• Does it update all target systems correctly?

---

12) Monitor and alert

Add observability for:

• webhook receipt rate
• signature failures
• processing latency
• downstream API failures
• retry counts
• unprocessed events

Alert on:

• spike in invalid signatures
• backlog growth
• failed syncs for VIP events
• missing check-in updates

---

13) Simple reference architecture

Ticketing platform
→ sends webhook

Webhook API endpoint
→ authenticates, stores raw event

Queue
→ buffers processing

Worker service
→ transforms event
→ upserts records in CRM / DB / access control

Audit DB
→ stores event history and external IDs

---

14) Minimal implementation example

Pseudo-flow:

def webhook_handler(request):
    raw = request.body
    signature = request.headers["X-Signature"]

    if not verify_hmac(raw, signature, SECRET):
        return 401

    event = json.loads(raw)

    if event_already_processed(event["event_id"]):
        return 200

    store_event(event)
    queue_event(event["event_id"])

    return 200

Worker:

def process_event(event_id):
    event = load_event(event_id)

    if event["event_type"] == "order.created":
        sync_customer(event["data"])
        sync_attendees(event["data"])
    elif event["event_type"] == "attendee.checked_in":
        update_attendance(event["data"])

---

15) Recommended integration checklist

• Identify source-of-truth system
• List webhook event types
• Build HTTPS receiver
• Verify signatures
• Store raw events
• Deduplicate by event ID
• Process asynchronously
• Map order/attendee IDs across systems
• Define sync rules
• Add retries and dead-letter handling
• Protect PII
• Test sandbox and failure cases
• Monitor and alert

---

If you want, I can also give you:

1. a sample architecture diagram,
2. a Node.js / Python webhook receiver example, or
3. a database schema for orders + attendees + sync mappings.