Changelog
Apps DocsCommunity

New `updates` fields

In version 2025-01, we added two new fields on updates queries:

  • edited_at: Returns the date the update's body was last edited
  • watchers: Returns data about the update's viewers
query {
  updates {
    body
    edited_at
    watchers {
      user_id
      medium
      user {
        name
      }
    }
  }
}

let query = "query { updates { body edited_at watchers { user_id medium user { name }}}}";

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)));

New `app_subscriptions` object

In API versions 2025-01 and later, we added the app_subscriptions object that enables you to query all of your app's subscriptions.

This call only works for app collaborators. 

query {
  app_subscriptions (app_id: 1234567890) {
    cursor
    total_count 
    subscriptions {
      account_id
      monthly_price
      currency
    }
  }
}

Upgrading GraphQL query validation to be more compliant

We recently introduced an upgraded GraphQL parser that enforced GraphQL specification query validations that were previously ignored. The API schema did not change.

This was done to provide a more reliable and consistent API experience while also simplifying integrations with other GraphQL-compliant tools.

This upgrade caused queries that previously passed validation in 2024-07 to fail in 2024-10.

Solution

To avoid any breaking changes in version 2024-10, we've made the new parser backward compatible. This means that you can request 2024-10 in the API-Version header to continue using the query successfully.

From 2025-01 onwards, some validation rules will be introduced as breaking changes. You will then need to adjust your queries according to the documented schema. Queries that don't meet these standards may fail.

Impact

This fix impacts a variety of queries, including those that use a line break inside of a string or send null in a non-nullable field. If you switch to 2024-10 and encounter any unannounced breaking changes, please open a support ticket to report it to the team.

Test your queries

If you want to test your query, we recommend using the API playground. Before running the query, if any of it is not valid, you should see a syntax error in red on the left side. In versions 2024-10 and earlier, the query will still run successfully despite the error.

Examples

Line breaks

For scenarios that do not involve line breaks directly within string values, 2024-10 and earlier would accept the input in the example below.

mutation {
 change_multiple_column_values (
  item_id: 2973338210,
  board_id: 2973338169,
  column_values: "{
  	\"link__1\": 
  	{\"url\": \"www.example.com\",\"text\": \"link url\"}
 		}")
{ id }
}

Now, version 2025-01 will expect the string as a single line.

mutation {  
  change_multiple_column_values(  
    item_id: 9876543210,  
    board_id: 1234567890,  
    column_values: "{\"link__1\": {\"url\": \"https://www.example.com\", \"text\": \"link url\"}}"
  ) { 
    id 
  }  
}

Null values

Versions 2024-10 and earlier sometimes accepted null values for non-nullable fields. 

query {
  boards (ids: 1234567890) {
    items_page (limit: 1, query_params: {
      rules: [
        {column_id: "checkbox", compare_value: [null], operator: is_not_empty}
      ]
    }) {
      items {
        id
        name
      }
    }
  }
}

Version 2025-01 will not accept null, so you have to send an empty compare_value. 

query {
  boards (ids: 1234567890) {
    items_page (limit: 1, query_params: {
      rules: [
        {column_id: "checkbox", compare_value: [], operator: is_not_empty}
      ]
    }) {
      items {
        id
        name
      }
    }
  }
}

Unified format for API errors

Big update for version 2025-01 and beyond: errors now have a consistent format compliant with the GraphQL specification!

This may be a breaking change for your application. Use version 2024-10 until you migrate your applications to handle the new error structure.

Errors will be returned in the following format:

  • HTTP status: Response will be 200 – OK for application-level errors. Other statuses will be returned for transport-layer errors, such as 429 - Too many requests or 400 - Bad request
  • JSON response: Body will contain an errors array with further details about each error
  • Partial data: Your query may return partial data and throw errors. In that case, you will receive both the data and errors objects. If a field throws an error, it will return null.

Examples:

{
  "data": [],
  "errors": [
    {
      "message": "User unauthorized to perform action",
      "locations": [
        {
          "line": 2,
          "column": 3
        }
      ],
      "path": [
        "me"
      ],
      "extensions": {
        "code": "UserUnauthorizedException",
        "error_data": {},
        "status_code": 403
      }
    }
  ],
  "account_id": 123456
}

{
  "data": {
    "me": {
      "id": "4012689",
      "photo_thumb": null
    },
    "complexity": {
      "query": 12
    }
  },
  "errors": [
    {
      "message": "Photo unavailable.",
      "locations": [
        {
          "line": 4,
          "column": 5
        }
      ],
      "path": [
        "me",
        "photo_thumb"
       ],
      "extensions": {
        "code": "ASSET_UNAVAILABLE"
      }
    }
  ],
  "account_id": 18888528
}

New create and delete teams mutations

We added two new mutations to create and delete teams via the API to versions 2025-01 and later.

Create team

mutation {
  create_team (input: {name: "New team", is_guest_team:false, subscriber_ids: [1234567890, 9876543210]}, options: {allow_empty_team: false}) {
    id
  }
}

Delete team

mutation {
  delete_team (team_id: 1234567890) {
    id
  }
}