Receiving Resamania events on your webhook endpoint

Listen for Resamania events occurring on your clientTokens/clubs at your webhook endpoint so your integration can automatically trigger the appropriate reactions.

Why use webhooks?

When building Resamania integrations, you might want your applications to receive events as they happen on the clientTokens/clubs you operate on, so your back-end systems can execute actions accordingly.

Receiving webhook events is especially useful when you need to be notified of changes to entity states without having to poll the Resamania API regularly.

To enable webhook events, contact support or the API team and provide the URL where you want to receive events.

Only one URL can be configured. This URL will receive all events.

If you use our API across multiple environments (prod, sandbox, overseas, ...), the webhook call does not indicate which environment the event comes from. You must therefore provide a separate URL for each environment to differentiate them.

Event overview

All events have the same JSON representation. It is sent in the body of the request, itself sent via HTTP POST.

Structure of the Event object

It contains 2 properties:

1. event which is the name of the event that occurred (string)
2. data which is an object containing 2 pieces of information
   1. The clubId where the event occurred
   2. The {object}Id, the name of which depends on the entity involved. The value is the identifier of that object.

Example event payload

The following event indicates that a booking was made.

{
    "event": "attendee.booked",
    "data": {"object":{"attendeeId":"/stadline/attendees/6", "clubId": "/stadline/clubs/1"}}
}

The different event types

Currently, 7 events are available.

Creation of a new contact

The data.object then contains the contactId corresponding to the created contact.

{
    "event": "contact.created",
    "data": {"object":{"contactId":"/stadline/contacts/2", "clubId": "/stadline/clubs/1"}}
}

Update of a contact

The data.object then contains the contactId corresponding to the updated contact.

{
    "event": "contact.updated",
    "data": {"object":{"contactId":"/stadline/contacts/2", "clubId": "/stadline/clubs/1"}}
}

Deletion of a contact

The data.object then contains the contactId corresponding to the deleted contact.

{
    "event": "contact.deleted",
    "data": {"object":{"contactId":"/stadline/contacts/2", "clubId": "/stadline/clubs/1"}}
}

Update of a contact's opt-ins (communication consents)

The data.object then contains the optinId and contactId corresponding respectively to the consent and the contact concerned.

{
    "event": "optin.updated",
    "data": {"object":{"optinId":"/stadline/optins/5", "contactId":"/stadline/contacts/2", "clubId": "/stadline/clubs/1"}}
}

A new booking recorded

• For attendees moving from waitlist to main list
• For attendees directly on the main list The data.object then contains the attendeeId corresponding to the attendee recorded for the booking.

{
    "event": "attendee.booked",
    "data": {"object":{"attendeeId":"/stadline/attendees/6", "clubId": "/stadline/clubs/1"}}
}

A booking cancellation

The data.object then contains the attendeeId corresponding to the attendee who cancelled the booking.

{
    "event": "attendee.canceled",
    "data": {"object": {"attendeeId": "/stadline/attendees/1", "clubId": "/stadline/clubs/1"}}
}

Creation or update of a class event

The data.object then contains the classEventId corresponding to the updated class event.

{
    "event": "class_event.updated",
    "data": {"object": "classEventId": "/stadline/class_events/1", "clubId": "/stadline/clubs/2"}
}

Cancellation of a class event

The data.object then contains the classEventId corresponding to the canceled class event.

{
    "event": "class_event.canceled",
    "data": {"object": "classEventId": "/stadline/class_events/2", "clubId": "/stadline/clubs/1"}
}

Warnings

Your webhook endpoint must be open

Your URL must be publicly accessible on the web, without any access restriction (authentication, rate limiting, ...).

Only one chance to receive the event

Our system does not retry if your webhook endpoint fails: If the called URL responds with an error (500, 403, ...), we will not attempt to call it again later.

This means you:

• Should ideally monitor your endpoint to ensure proper handling of received events
• Should consider logging the received events and their processing status
• May keep a strategy of regularly fetching data from our APIs in addition to webhooks

For this last case: For example, you might regularly receive attendee.booked and attendee.canceled events but still want to GET /{client_token}/attendees every hour to compare the list against your records.

Setup

Contact support or the API team so your URL can be configured on the Sandbox environments for your initial tests. You will then have to trigger the events yourself.

Once your integration is validated, contact support or the API team again to have your URL configured on the production environments.