This feature is currently in Beta, meaning it is actively being tested and refined before a full release. It is not available to all organizations. Access is limited to clubs in CourtReserve's Early Access Groups. To request access, contact our Customer Support team via live chat or email.
CourtReserve Webhooks enable real-time, action-triggered integration with external platforms by automatically sending data to your systems the moment activity occurs within your organization. Instead of polling the API repeatedly for updates, webhooks deliver data instantly — improving efficiency, reducing unnecessary API calls, and keeping your integrations synchronized without delay.
Built for reliability and performance, webhooks support only HTTPS requests and JSON data, ensuring secure and consistent communication.
Note: CourtReserve webhooks are configured and managed at the organization level. Enterprise-level webhooks are not currently supported.
Webhook Access Setup
Webhooks are available on the Advanced, Momentum, and Enterprise plans.
How Webhooks Work
When a subscribed action, or event, occurs in CourtReserve, an HTTP POST request is automatically sent to your configured endpoint URL. The request contains a JSON payload with details about the event. Your endpoint must be publicly accessible over HTTPS and must respond with an HTTP 200 status within the configured timeout window to confirm successful receipt.
Webhook Configuration
When creating a webhook, you can configure the following parameters:
Endpoint URL (required): The public HTTPS URL where CourtReserve will send webhook data. Must be publicly accessible on the internet.
Event Types: Choose which events should trigger this webhook. Leave empty to receive all events.
Description (optional): A label to identify the webhook's purpose, especially useful when managing multiple webhooks.
Custom Headers (optional): Custom headers allow you to append additional key-value pairs to the HTTP request headers included in every webhook delivery. Common use cases include passing an
Authorizationtoken orx-api-keyfor endpoint authentication, or including platform-specific metadata required by your receiving system. Your developer or integration platform will supply the exact header name and value.Timeout: The maximum time CourtReserve waits for your endpoint to respond before treating the delivery as failed. Configurable between 1–60 seconds (default: 30 seconds).
Webhook Event Types
CourtReserve webhooks support a comprehensive range of event types across key areas of the platform. When creating a webhook, you can select specific events to subscribe to or leave the selection empty to receive all event types.
Events & Programs
Event Type | Description | Key Data Fields |
event.created | Fired when a new event or program is created | eventId, name, startDate, endDate, organizationId |
event.updated | Fired when an event or program is modified | eventId, name, startDate, endDate, organizationId |
event.deleted | Fired when an event or program is deleted | eventId, organizationId |
event.cancelled | Fired when an event or program is cancelled | eventId, organizationId |
Event Registrations
Event Type | Description | Key Data Fields |
event_registration.created | Fired when a member registers for an event | registrationId, eventId, memberId, registeredAt |
event_registration.cancelled | Fired when an event registration is cancelled | registrationId, eventId, memberId, cancelledAt |
Members
Event Type | Description | Key Data Fields |
member.created | Fired when a new member is added to an organization | memberId, firstName, lastName, email, organizationId |
member.deleted | Fired when a member is removed from an organization | memberId, organizationId |
member.updated | Fired when a member is modified | profile_updated, approved, declined, login_updated, family_changed, membership_assigned, membership_cancelled, membership_suspended, membership_reactivated |
Reservations
Event Type | Description | Key Data Fields |
reservation.created | Fired when a new reservation is created | reservationId, memberId, courtId, startTime, endTime |
reservation.updated | Fired when a reservation is modified | reservationId, memberId, courtId, startTime, endTime |
reservation.cancelled | Fired when a reservation is cancelled | reservationId, memberId, cancelledAt |
Security & Authentication
Each webhook request includes cryptographic headers to allow your endpoint to verify the authenticity of the request and confirm it originated from CourtReserve:
X-CourtReserve-Timestamp: The Unix timestamp indicating when the request was sent.
X-CourtReserve-Signature: A cryptographic HMAC-SHA256 signature that uniquely identifies the request.
Verifying Webhook Requests
Each webhook request sent by CourtReserve includes a signature that allows your endpoint to confirm the request is legitimate. To verify a request, your endpoint should follow these steps:
Extract the X-CourtReserve-Timestamp header value
Build the signing string: {timestamp}.{rawBody}
Compute HMAC-SHA256 using your signing secret (strip the whsec_ prefix and Base64-decode it)
Compare the result with the X-CourtReserve-Signature header
Signing Secret
Your signing secret is generated when a webhook is first created and is displayed one time only. Copy and store it securely before closing the window, as it cannot be retrieved again. If your secret is ever lost or compromised, select Rotate Secret from the webhook's actions menu to invalidate the current secret and generate a new one.
Reliability & Retry Behavior
CourtReserve ensures reliable webhook delivery with automatic retry logic. If your endpoint fails to respond or returns an error, CourtReserve will automatically retry the request up to 3 times before marking it as Dead Lettered. You can monitor all delivery attempts, statuses, and outcomes through the Delivery Log associated with each webhook.
Delivery statuses include:
Pending — queued and awaiting delivery
Succeeded — successfully received by your endpoint
Failed — endpoint did not respond as expected
Dead Lettered — all retry attempts have been exhausted
Webhook Management
After creating a webhook, you can manage it using the following actions:
Edit: Update the endpoint URL, event types, description, custom headers, or timeout settings.
Delivery Log: View the complete history of webhook deliveries, including status and timestamps.
Send Test: Fire a test message to your endpoint to verify the connection is working without affecting real data.
Rotate Secret: Invalidate the current signing secret and generate a new one if compromised.
Enable / Disable: Temporarily pause webhook delivery without deleting the subscription.
Delete: Permanently remove the webhook subscription.