What is a ticketing webhook?
A ticketing webhook is an automated notification sent from a ticketing system to another application when a defined event occurs. For example, a ticketing platform can notify a customer relationship management (CRM) system after an order is completed, allowing the CRM to update its records without repeatedly checking for new sales.
Most webhooks use an HTTP request sent to a receiving endpoint. Which events, payloads and delivery guarantees are supported depends on the provider and integration configuration.
How do ticketing webhooks work?
A webhook delivers information because something happened in the ticketing platform, rather than because the receiving system asked for it.
A typical order-update workflow is:
- An administrator configures a webhook for a supported event, such as ‘order completed’.
- The receiving application exposes a secure URL to accept notifications.
- The ticketing system records an order completion and prepares a notification with a defined payload.
- It sends the notification to the recipient, which verifies the request and records or processes the event.
- The receiver acknowledges the request and, if necessary, retrieves further authoritative order details through an API.
The exact message could include an event type, event identifier, timestamp and order reference. These are common design elements, not a promise that all ticketing platforms send identical fields.
Illustrative example: A theatre uses one system for selling tickets and another for email communications. When someone completes an eligible purchase, a webhook alerts the communications system so it can schedule a relevant pre-event message, subject to the organisation’s permissions and consent rules.
Which ticketing events can trigger webhooks?
Webhooks commonly connect sales, customer and event operations to external systems. Providers may offer notifications for completed or failed orders, refunds, new events, attendee check-ins, check-outs and other workflow changes.
A webhook catalogue should say precisely when each notification fires, what the payload contains and which account or event permissions apply. Without that information, an integration can interpret an interim state as final.
How are webhooks different from polling an API?
Webhooks let a provider push event notifications; polling makes the receiving application repeatedly ask for updates.
Polling can be appropriate when an API has no event notifications or when regular reconciliation is needed. But polling every few seconds across thousands of orders can create unnecessary requests and may still miss a state change between checks.
Webhooks can reduce that overhead and provide faster notification of events. They do not guarantee an immediate or exactly-once update. A reliable integration may combine incoming notifications with periodic checks against the authoritative ticketing API.
For example, a CRM could process completed-order webhooks during the day, then run a reconciliation against confirmed orders each night to find missing updates. Whether the provider supports an appropriate query for this depends on its API coverage.
What happens if a webhook is delivered twice or arrives late?
Webhook consumers should be designed to handle duplicate, delayed and potentially out-of-order notifications. The same order completion may arrive more than once, especially if the first delivery succeeded but the provider never received a successful acknowledgement.
Suppose the CRM receives an order-completed event twice. If it blindly creates a new purchase record each time, it may double-count revenue or send duplicate emails. A safer design records an event identifier or uses an order-level deduplication key before applying the side effect.
If the recipient is unavailable, the provider might retry according to its documented policy. The receiver should respond promptly and move slow work into its own queue where appropriate. Retry rules, retention windows and manual replay features vary; they should be verified rather than assumed.
Because webhook events can arrive in a different order from the underlying changes, the receiving application should not automatically treat the last notification received as the latest business state. It may need to fetch the current status from the ticketing API.
How should ticketing webhooks be secured?
A webhook endpoint should verify that incoming requests are authorised and authentic before acting on them. HTTPS protects data in transit, but HTTPS alone does not prove a message actually came from the expected provider.
Depending on the platform, verification may use a signed payload, secret, shared credential or other supported mechanism. Signing details differ by provider, so receivers must follow the documented scheme exactly.
Other safeguards include using dedicated endpoint credentials, validating payload structure, limiting accepted event types, logging delivery identifiers without exposing sensitive data and restricting access to customer records.
Never assume that knowing an endpoint URL is sufficient authentication. An attacker who can forge a purchase-completed notification could otherwise influence downstream fulfilment or marketing workflows.
Do webhooks contain the full order or customer record?
Not necessarily. Some webhooks contain complete permitted event data; others contain identifiers that let the recipient request further information. The second approach can reduce unnecessary distribution of personal data and keep the ticketing service as the authoritative source.
A recipient may receive a ticket identifier and an event reference, then use scoped API credentials to retrieve only the fields its task requires. That is a deliberate design choice: webhook receipt does not inherently grant access to every customer or event record.
When customer data crosses organisational boundaries, teams also need to consider privacy, retention and contractual responsibilities. Technical delivery is only one part of lawful and appropriate data sharing.
When should a ticketing integration use webhooks?
Webhooks are useful when downstream systems need to react to changes: order confirmation, access-control events, refunds or newly published events. They are less useful when the question is simply ‘Which events are available right now?’—a direct API enquiry may be more suitable.
Before implementation, ask: Which events are exposed? Are test notifications available? How are requests authenticated? What is the duplicate/retry policy? Can missed events be recovered? Are events partitioned by organiser or company? What data is included, and what must be fetched separately?
A good webhook integration treats notifications as reliable signals to investigate and process, not as an excuse to stop validating the underlying ticketing state.