How AI is applied across API Evangelist and APIs.io. Read my AI disclosure →
API Evangelist API Evangelist
Discovery
Learnings
Guidance
Toolbox
Alignment
API Evangelist LLC

ilert Notification Preferences API

The Notification Preferences API from ilert — 8 operation(s) for notification preferences.

ilert Notification Preferences API is one of 33 APIs that ilert publishes on the APIs.io network, described by a machine-readable OpenAPI specification.

This API exposes 1 JSON Schema definition.

Tagged areas include Notification Preferences. The published artifact set on APIs.io includes an OpenAPI specification, API documentation, authentication docs, rate-limit docs, and 1 JSON Schema.

This API exposes 20 operations across 8 paths, and defines 20 schemas. It is described by OpenAPI 3.2.0, at version v2.2026.5-r.3.

Requests are made against a single base URL, /api.

20 operations 8 paths 20 schemas 4 DELETE8 GET4 POST4 PUT

Metadata

The identity and technical contract details declared by the specification.

Specification
OpenAPI 3.2.0
API Version
v2.2026.5-r.3
Base URL
https://api.ilert.com
Authentication
API Key
Resource Areas
1

Authentication & Security 1

ilert Notification Preferences API declares 1 security scheme for authenticating requests. An API key is passed in the header as Authorization (apiKey). By default, every request must be authenticated.

  • apiKey — The Bearer API key of your user more info .

Paths & Operations 20

Across 8 paths, the API surfaces 20 operations — 4 DELETE, 8 GET, 4 POST, 4 PUT. Each is listed below with its method, path, parameters, and response codes.

Notification Preferences 20
GET
/users/{user-id}/notification-preferences/alerts
Get alert notification preferences of a user
1 param → 200
POST
/users/{user-id}/notification-preferences/alerts
Create an alert notification preference
1 param body → 201
GET
/users/{user-id}/notification-preferences/alerts/{id}
Get specific notification preferences alert
2 params → 200
PUT
/users/{user-id}/notification-preferences/alerts/{id}
Update a user's alert notification preference
2 params body → 200
DELETE
/users/{user-id}/notification-preferences/alerts/{id}
Delete the user's specified notification preferences alert
2 params → 204
GET
/users/{user-id}/notification-preferences/duties
Get duty notification preferences of a user
1 param → 200
POST
/users/{user-id}/notification-preferences/duties
Create a duty notification preference
1 param body → 201
GET
/users/{user-id}/notification-preferences/duties/{id}
Get specific notification preferences duty
2 params → 200
PUT
/users/{user-id}/notification-preferences/duties/{id}
Update a user's duty notification preference
2 params body → 200
DELETE
/users/{user-id}/notification-preferences/duties/{id}
Delete the user's specified notification preferences duty
2 params → 204
GET
/users/{user-id}/notification-preferences/updates
Get update notification preferences of a user
1 param → 200
POST
/users/{user-id}/notification-preferences/updates
Create an update notification preference
1 param body → 201
GET
/users/{user-id}/notification-preferences/updates/{id}
Get specific notification preferences update
2 params → 200
PUT
/users/{user-id}/notification-preferences/updates/{id}
Update a user's update notification preference
2 params body → 200
DELETE
/users/{user-id}/notification-preferences/updates/{id}
Delete the user's specified notification preferences update
2 params → 204
GET
/users/{user-id}/notification-preferences/subscriptions
Get subscription notification preferences of a user
1 param → 200
POST
/users/{user-id}/notification-preferences/subscriptions
Create a subscription notification preference
1 param body → 201
GET
/users/{user-id}/notification-preferences/subscriptions/{id}
Get specific notification preferences subscription
2 params → 200
PUT
/users/{user-id}/notification-preferences/subscriptions/{id}
Update a user's subscription notification preference
2 params body → 200
DELETE
/users/{user-id}/notification-preferences/subscriptions/{id}
Delete the user's specified notification preferences subscription
2 params → 204

Schemas 20

The contract defines 20 schemas that model the data the API accepts and returns. The most detailed are NotificationPreferencesDuty (5 properties), NotificationPreferencesAlert (5 properties), ContactPhoneNumber (5 properties), NotificationPreferencesDutyPost (4 properties). Each schema is shown below with its type and property counts.

NotificationPreferenceSubscriptionMethod
string
ContactStatus
string
NotificationPreferencesSubscription
object
3 properties
NotificationPreferenceAlertType
string
NotificationPreferencesDuty
object
5 properties
NotificationPreferencesAlert
object
5 properties
ContactEmail
object
3 properties
NotificationPreferencesDutyBeforeMin
integer
NotificationPreferenceDutyMethod
string
NotificationPreferencesUpdate
object
4 properties
NotificationPreferencesUpdateType
string
NotificationPreferencesDutyTypes
string
NotificationPreferenceAlertMethod
string
NotificationPreferenceUpdateMethod
string
NotificationPreferencesDutyPost
object
4 properties
NotificationPreferencesUpdatePost
object
3 properties
NotificationPreferencesAlertDelayMin
integer
NotificationPreferencesSubscriptionPost
object
2 properties
NotificationPreferencesAlertPost
object
4 properties
ContactPhoneNumber
object
5 properties

Specification

The full machine-readable OpenAPI contract behind this narrative.

Source

ilert-notification-preferences-api-openapi.yml Raw ↑

Other APIs ilert publishes across the network.

ilert Alert Actions API
ilert Alert Sources API
ilert Alerts API
ilert Call Flow Numbers API
ilert Call Flows API
ilert Connectors API
ilert Contacts API
ilert Deployment Events API
ilert Deployment Pipelines API
ilert Escalation Policies API
ilert Event Flows API
ilert Events API
Where this information came from

This is an independent, third-party profile of ilert Notification Preferences API, published by API Evangelist. We do not operate, host, resell, or support these APIs, and we are not affiliated with or endorsed by the company unless stated above. Everything here is built from publicly available information — the company's own site, developer portal, documentation, public repositories, and the specifications it publishes for public use. Nothing is obtained by breaching a system, defeating an access control, or using credentials.

The Kin Score and Agent Readiness rating are independently calculated assessments of a company's public API artifacts, scored against a published rubric. They are not certifications, endorsements, security assessments, or audits.

Corrections, re-scores, and removal are free — no partnership or purchase required, and you do not need to justify the request. A removed company is recorded as unrated, never scored zero for having asked. Acknowledgement within one business day; removal within two.

info@apievangelist.com · Read the full data-sourcing policy →
On a security or compliance team? Put security in the subject line and you will get a person, not a form — we will tell you exactly which public URLs this profile was built from.