Notifications

Learn how to create notifications on monday using the platform API

Notifications alert users of platform activities, such as due dates, updates, and more. They appear in multiple locations, including the bell icon and email.

Notifications relevant only to the signed-in user appear under the bell icon. By default, they will also receive an email whenever they get a notification. This can be turned off and customized in the user’s profile settings.

Queries

query {
  notifications (filter_read: true) {
		text
    title
    id
  }
}
{
  "data": {
    "notifications": [
      {
        "text": "This is a notification",
        "title": "New test notification",
        "id": "123456"
      }
    ]
  },
  "extensions": {
    "request_id": "YOUR_REQUEST_ID"
  }
}

Arguments

You can use the following arguments to reduce the number of results returned in your notifications query.

ArgumentDescription
cursor IDThe unique identifier of the last notification to retrieve.
filter_read BooleanWhether to retrieve only unread notifications.
limit IntThe number of notifications returned. The default is 25.
since ISO8601DateTimeFilter notifications from this date (inclusive).

Fields

You can use the following fields to specify what information your notifications query will return. Please note that some fields will have their own arguments.

FieldDescription
board BoardThe board associated with the notification.
created_at DateThe notification's creation date.
creators [User!]!The notifications creator(s).
id ID!The notification's unique identifier.
item ItemThe item associated with the notification.
read Boolean!Whether the notification has been read.
text StringThe notification's text.
title StringThe notification's title.
update UpdateThe update associated with the notification.

Mutations

Required scope: notifications:write

Create a notification

The create_notification mutation allows you to send a notification to the bell icon via the API. Doing so may also send an email if the recipient's email preferences are set up accordingly.

If you send a notification from a board view or widget using seamless authentication, it will be sent from the app and display its name and icon. If you use a personal API key to make the call, the notification will appear to come from the user who installed the app on the account.

This mutation only sends the notification. Since notifications are asynchronous, you can't query back the notification ID when running the mutation.

mutation {
  create_notification (user_id: 12345678, target_id: 674387, text: "This is a notification", target_type: Project) {
    text
  }
}
let query = "mutation { create_notification (user_id: 12345678, target_id: 674387, text: \"This is a notification\", target_type: Project) { text } }";

fetch ("https://api.monday.com/v2", {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    'Authorization' : 'YOUR_API_KEY_HERE'
   },
   body: JSON.stringify({
     query : query
   })
  })
   .then(res => res.json())
   .then(res => console.log(JSON.stringify(res, null, 2)));

Arguments

You can use the following argument(s) to define the new notification's characteristics.

ArgumentDescriptionEnum values
target_id ID!The target's unique identifier. The value depends on the target_type:

Post: update or reply ID
Project: item or board ID
target_type NotificationTargetType!The target's type.Post (sends a notification referring to an update or reply)
Project (sends a notification referring to an item or board)
text String!The notification's text.
user_id ID!The user's unique identifier.