RESTful

See API guide

YOUnite UI is an example of an application that consumes the YOUnite API.

Zones & Permissions

zones

permissions

access tokens

UI and seeing effective permissions

Scopes

See XYZ for overview of scopes.

Inbound

Setting

Outbound

Setting

Getting Data Records

Making Data Record Changes

PUT, PATCH and Change Versions

All mutable resources contain a changeVersion that is used as a semaphore to control concurrent access. For example, if an API consumer wants to PUT or PATCH a resource they must use the following sequence:

...

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.

Receiving Data Record Changes

Event Notifications & Webooks

Webhooks allow applications to setup integrations which subscribe to certain YOUnite events. An API consumer integrates a webhook by following these steps:

...

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 (Remove this and replace with something that doesn't cover the MB)

Response Codes

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.

...