Receive Resamania events on your webhook endpoint

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

Why use webhooks?

When building Resamania integrations, you may want your applications to receive events as they occur on the clientTokens/clubs you operate on, so that your back-end systems can take action accordingly.

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

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

Only one URL can be configured, and it will receive all events.

If you use our API across multiple environments (prod, sandbox, overseas territories, etc.), webhook calls do not indicate which environment the event comes from. You must therefore provide one URL per environment in order to distinguish them.

Event overview

All events share the same JSON representation. It is sent in the request body, using the HTTP POST method.

Event object structure

It contains 2 properties:

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

Example event payload

The following event indicates that a booking has been made.

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

Event types

Contact events

Creation of a new contact

The data.object then contains the contactId of the created contact.

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

Contact update

The data.object then contains the contactId of the updated contact.

Note: When is the contact.updated webhook triggered? This event is triggered when contact information is modified, including when the contact changes status (prospect, client, former client, banned), but not when the contact gains or loses tags.

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

Contact deletion

The data.object then contains the contactId of the deleted contact.

Warning

This webhook should not trigger a GET call since you would receive a 404 by default, as the contact no longer exists. It is useful if you store contactId values in a database that you need to clean up (e.g., GDPR compliance).

{
    "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 the contactId corresponding respectively to the consent and the related contact.

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

Booking events

New booking registration

• For attendees moving from the waiting list to the main list
• For attendees booking directly on the main list

The data.object then contains the attendeeId of the registered attendee.

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

Booking cancellation

The data.object then contains the attendeeId of the attendee who canceled the booking.

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

Creation or update of a group class

The data.object then contains the classEventId of the updated group class.

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

Group class cancellation

The data.object then contains the classEventId of the canceled group class.

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

Subscription events

Subscription deletion

The data.object then contains the subscriptionId of the deleted subscription.

{
    "event": "subscription.deleted",
    "data": {"object": {"subscriptionId":"/stadline/subscriptions/1", "clubId":"/stadline/clubs/1"}}
}

Subscription option deletion

The data.object then contains the subscriptionOptionId of the deleted subscription option.

{
    "event": "subscription_option.deleted",
    "data": {"object": {"subscriptionOptionId":"/stadline/subscription_options/1", "clubId":"/stadline/clubs/1"}}
}

AccountingContactTag creation

The data.object then contains the created accountingContactTagId for the contact identified by contactId.

{
    "event": "accounting_contact_tag.created",
    "data": {"object": {"accountingContactTagId":"/stadline/accounting_contact_tags/1", "contactId":"/stadline/contacts/1"}}
}

AccountingContactTag update

The data.object then contains the updated accountingContactTagId for the contact identified by contactId.

{
    "event": "accounting_contact_tag.updated",
    "data": {"object": {"accountingContactTagId":"/stadline/accounting_contact_tags/1", "contactId":"/stadline/contacts/1"}}
}

AccountingContactTag deletion

The data.object then contains the deleted accountingContactTagId for the contact identified by contactId.

{
    "event": "accounting_contact_tag.deleted",
    "data": {"object": {"accountingContactTagId":"/stadline/accounting_contact_tags/1", "contactId":"/stadline/contacts/1"}}
}

Contact tag creation

The data.object then contains the created contactTagId for the contact identified by contactId.

{
    "event": "contact_tag.created",
    "data": {"object": {"contactTagId":"/stadline/contact_tags/1", "contactId":"/stadline/contacts/1"}}
}

Contact tag update

The data.object then contains the updated contactTagId for the contact identified by contactId.

{
    "event": "contact_tag.updated",
    "data": {"object": {"contactTagId":"/stadline/contact_tags/1", "contactId":"/stadline/contacts/1"}}
}

Contact tag deletion

The data.object then contains the deleted contactTagId for the contact identified by contactId.

{
    "event": "contact_tag.deleted",
    "data": {"object": {"contactTagId":"/stadline/contact_tags/1", "contactId":"/stadline/contacts/1"}}
}

Badge events

Badge creation

The data.object then contains the created identificatorId for the contact identified by contactId.

{
    "event": "identificator.created",
    "data": {"object": {"indentificatorId":"/stadline/identificators/1","targetId":"/stadline/contacts/1"}}
}

Badge update

The data.object then contains the updated identificatorId for the contact identified by contactId.

{
    "event": "identificator.updated",
    "data": {"object": {"indentificatorId":"/stadline/identificators/1","targetId":"/stadline/contacts/1"}}
}

Badge deletion

The data.object then contains the deleted identificatorId for the contact identified by contactId.

{
    "event": "identificator.deleted",
    "data": {"object": {"indentificatorId":"/stadline/identificators/1","targetId":"/stadline/contacts/1"}}
}

Badge disabling

The data.object then contains the disabled identificatorId for the contact identified by contactId.

{
    "event": "identificator.disabled",
    "data": {"object": {"indentificatorId":"/stadline/identificators/1","targetId":"/stadline/contacts/1"}}
}

Warnings

Your webhook endpoint must be publicly accessible

Your URL must be publicly accessible on the web, with no access restrictions (authentication, rate limiting, etc.).

Only one chance to receive the event

Our system does not retry webhook delivery if your endpoint fails. If the called URL responds incorrectly (500 error, 403 error, etc.), we will not attempt to call it again automatically.

This implies that you:

• Should ideally monitor your endpoint to ensure proper processing of received events
• Should consider logging received events and their processing status
• May maintain a regular data recovery strategy using our APIs, in addition to webhooks

In the latter case, for example, you may regularly receive attendee.booked and attendee.canceled events but still fetch GET /{client_token}/attendees every hour to reconcile the list with the one you maintain.

Setup

Contact the support/API teams so that your URL is configured on sandbox environments to run your first tests. You will then need to trigger the events yourself.

Once your integration is validated, contact the support/API teams again so that your URL is configured on production environments.