...
If the changeVersion has been changed by another consumer since the GET request (#1 above), a 409 will be returned and the consumer will need to repeat the sequence again.
Event Notifications & Webooks
Webhooks
...
Notification Event Types
The allow applications to setup integrations which subscribe to certain YOUnite events. An API consumer integrates a webhook by following these steps:
- Create an URL endpoint where YOUnite notifications can be delivered.
- when an event occurs, a notification is triggered and an HTTP POST payload is sent to this URL endpoint.
- Register the URL endpoint with YOUnite and configure which events the consumer wants to subscribe to.
When a YOUnite subscribed event occurs, the consumer will receive an HTTP POST request and payload to the registered URL endpoint.
YOUnite Events
When registering a webhook, the consumer chooses which events they want to subscribe to. The list of subscribed events can be changed at anytime. The following is list of event types that a subscriber can be notified of on a per zone (topic) basis. Each time an event is triggered it publishes a new notification of a given event type . zone basis:
| Default Scope | Additional PayloadZONEPOSTALLnone | | A zone is updated (including moved) |
ZONEPUTALL | none | ZONE_DELETE | ALL | noneA 's thumbnail image is updated (TBD)ZONE_THUMBNAIL_PUT | ALL | TBD | | _delete |
A data domain is created or a new version of of the data domain has been created |
DOMAIN_POST | ALL | TBD| domain_post |
A data domain has been |
createdDOMAINPUTALLTBD | | A data domain has been deleted |
DOMAINDELETEALL | TBD | | An MDR has been created for a given data domain (TBD) |
DOMAIN_NAME_DATA_POST | ALL | TBD | TBD| mdr_post |
| An MDR has been updated in a given data domain (TBD) |
DOMAIN_NAME_DATA_PUT | ALL | TBD| mdr_put |
| An MDR has been deleted in a give data domain (TBD) |
DOMAIN_NAME_DATA_DELETE | ALL |
Notification Event Response Body
The notification's JMS header s response body includes the following:
| key | value |
|---|
| description | A full description of the event - i.e. a full concatenation of the information described below for easy displaying. |
| changeVersion | The resources change version. |
| createdDate | The date the resource was created. |
| Name | The resource name |
| message-id | The JMS message ID. |
| dateCreated | Unix timestamp of when the event notification was sent |
uuid | Zone uuid of target resource |
| eventType | One of the above described "Notification Event Types" |
| originatorName | The name of the zone that generated the event. |
| originatorUuid | The UUID of the zone that generated the event. |
| timestamp | The time the notification was created. |
| actions | Some PUT & PATCH commands provide multiple actions and this list contains a description of what actions were performed. |
| optional | Other key/values that are appropriate for the notification type |
Requesting Notification Log
A client can make a request to get the log history for all notifications sent to their zone. The user provides their zone and a from and to date.
Message Broker
...
Internal Errors
It is always recommended that YOUnite is deployed in a highly-available configuration. Not only should YOUnite be highly-available but so should the underlying services that it depends upon e.g. database and message broker. If an API request is made to the YOUnite API service and one of the underlying services is experiencing a catastrophic failure, the YOUnite API service will return a 500 to the API consumer and the API consumer will have to retry their request.