Webhooks notify your application when data changes in the SportsEngine platform. Each organization can decide to enable webhooks to your application, and you can configure applications to receive webhooks at a specific URL. If you are not receiving webhooks for an organization, you can find their contact information in the /organizations query. Please look at the Completing Your First GraphQL Query for examples of accessing organization data.
Webhook Payload
Like GraphQL queries and mutations, webhooks send to your endpoint in a POST. The webhook payload will contain four attributes to describe what happened to the data. It is important to note that the payload does not have the exact changed data due to privacy concerns. A webhook payload example:
{
organizationId: 12345
resourceOperation: “create”
resourceId: "ab9f4201-4ef4-4a02-946f-81c3399959a2"
resourceType: “event”
} Attribute | Description |
organizationid | This attribute is used in most queries and is an integer. |
resourceOperation | This string informs what happened to the data. The values will be: create, update, or delete. |
resourceId | Typically, this alphanumeric string is the internal SportsEngine ID for the changed data. |
resourceType | This string indicates the type of data that changed. |
Operations for Webhook Resources
Webhooks send for a variety of objects on the platform. Since not all webhooks apply to every object, here is a quick breakdown of each resourceType and if they support create, update, or delete operations.
resourceType | Create | Update | Delete |
event | Yes | Yes | Yes |
affiliation | Yes, parent only | Yes, parent only | Yes, parent only |
profile | No | No | No |
team | Yes | Yes, includes any roster change | Yes |
registrationResult | Yes | Yes | Yes |
registration | No | No | No |
organization | Yes | Yes | Yes |
eligibility | Yes | Yes | N/A |
membership | Yes | Yes | N/A |
Frequency and Significant Operations
Webhook settings have a maximum of one webhook per object per minute per organization. Suppose multiple changes on an object within a minute can happen frequently on events and teams. In that case, it will be summarized in a single webhook with the most significant operation as the resource operation. For example, suppose an event is created and updated with a score within the same minute. In that case, you will receive one webhook only containing the create operation, as create is the most significant operation at that minute. The operation significance order:
Order | Operation |
1 | delete |
2 | create |
3 | update |
Webhook Retry Policy
Your application is responsible for being ready to receive webhooks. We send webhooks once and do not retry failed webhooks. If we receive errors for webhooks (non-200 status) for several days, we reserve the option to turn off webhooks for your application.