Alert responsibilities

Create, read, update and delete the alert responsibilities that say who handles alerts.

Alert responsibilities say who handles which alerts. You can list, create, read, update and delete them on the singular /alert_responsibility path. This area has 5 endpoints, and all seven SDKs call every one.

At a glance

Endpoint	Method	Path	What it does
List alert responsibilities	GET	/alert_responsibility	Lists the alert responsibilities on your instance, one page at a time.
Retrieve an alert responsibility	GET	/alert_responsibility/{alert_responsibility_id}	Retrieves one alert responsibility by its ar_ id or its raw uuid.
Create an alert responsibility	POST	/alert_responsibility	Creates an alert responsibility and returns it.
Update an alert responsibility	PATCH	/alert_responsibility/{alert_responsibility_id}	Changes an alert responsibility and returns it.
Delete an alert responsibility	DELETE	/alert_responsibility/{alert_responsibility_id}	Deletes an alert responsibility. Nothing comes back.

Before you call

Register your API credentials once when your app starts, as shown in Authentication. Every SDK sample on these pages then gets its client in one line. With cURL, send the access token in an Authorization header: Authorization: Bearer $ACCESS_TOKEN.

Things to know

• The path is singular. Use /alert_responsibility. The href and url values in these records say /alert_responsibilities.
• Writes are wrapped in alert_responsibility. name is required and unique; a create reads only name, display_name and description.
• Reads take the ar_ id or the raw uuid; the delete takes the ar_ id only.
• These are the same records as Alert responsibility settings. /settings/alert_responsibilities serves them too.
• In the SDKs this area is alert_responsibility (singular). alert_responsibilities is the Alert responsibility settings area.
• Listings page by cursor. Records sit under data; pass pagination.next_cursor as cursor to read the next page, and stop when pagination.has_more is false.