Using the new audit_event_catalogue object, you can retrieve a list of supported audit log events via the API. These can then be used to filter audit log results when querying the audit_logs object.
query {
audit_event_catalogue {
description
metadata_details
name
}
}
Enterprise account admins can now query the account's audit logs through the new audit_logs object. The paginated results can be filtered by user, start/end date, event types, and IP address.
query {
audit_logs(user_id: 1234567890, events: ["login", "logout"], limit: 100) {
logs {
timestamp
event
user_agent
user {
id
name
email
}
ip_address
}
pagination {
has_more_pages
next_page_number
}
}
}
You can now retrieve a user's permission level when querying board views using the new access_level field. It returns an enum value that specifies whether the user can view or edit the board.
query {
boards (ids: 1234567890) {
views {
type
settings_str
view_specific_data_str
name
id
access_level
}
}
}
We've added two new fields for boards queries:
access_level: Returns an enum value that specifies the user's board permission level.object_type_unique_identifier: Returns a unique identifier for the board's object type.query {
boards (ids: 1234567890) {
access_level
object_type_unique_identifier
items_page {
items {
id
name
}
}
}
}
We've updated the error code for unauthorized user actions from UserUnauthorizedException to USER_UNAUTHORIZED. This change helps maintain consistency with other standardized error codes in our API.
Here’s a comparison of the updated and previous responses:
{
"data": {
"me": null
},
"errors": [
{
"message": "User unauthorized to perform action",
"locations": [
{
"line": 1,
"column": 2
}
],
"path": [
"me"
],
"extensions": {
"code": "USER_UNAUTHORIZED",
"status_code": 403,
"error_data": {}
}
}
]
}
{
"data": {
"me": null
},
"errors": [
{
"message": "User unauthorized to perform action",
"locations": [
{
"line": 1,
"column": 2
}
],
"path": [
"me"
],
"extensions": {
"code": "UserUnauthorizedException",
"status_code": 403,
"error_data": {}
}
}
]
}
When querying updates at the root, you can now filter the results by a specific date range using the new from_date and to_date arguments. These arguments must be used together—using only one will return an error.
👉 Read more about updates here!
query {
updates (limit: 50, to_date: "2025-06-04", from_date: "2025-01-01") {
body
id
created_at
creator {
name
id
}
}
}
You can now mention users, teams, boards, and projects when creating updates using the new mentions_list argument in the create_update mutation.
👉 Read more here!
mutation {
create_update (item_id: 9876543210, body: "This update will mention user 1234567890 on an item", mentions_list: [{id: 1234567890, type: User}]) {
id
}
}
We've simplified the complexity budget exhausted error response to better align with other rate and limit errors. The response no longer includes budget-related fields such as complexity, complexity_budget_left, or status_code.
If you still need access to this data, you can retrieve it using the complexity endpoint.
Here’s a comparison of the old and new responses:
{
"errors": [
{
"message": "Complexity budget exhausted",
"extensions": {
"code": "COMPLEXITY_BUDGET_EXHAUSTED",
"retry_in_seconds": 60
}
}
]
}
{
"errors": [
{
"message": "Complexity budget exhausted",
"extensions": {
"code": "COMPLEXITY_BUDGET_EXHAUSTED",
"retry_in_seconds": 7,
"complexity": 11,
"complexity_budget_left": 4999967,
"complexity_budget_limit": 5000000,
"status_code": 429
}
}
]
}
This Sunday, the API will briefly be read-only for scheduled maintenance. Only accounts in the AU region will be affected. We estimate the maintenance will take less than 5 minutes.
During this time, queries will operate normally, but mutations will return an error. If you receive an error, please retry your API calls after a few minutes.
The maintenance will be at 12 am AEST or 2 pm UTC.
You can subscribe to updates on our status page: Maintenance on May 25th
Enterprise customers can now programmatically create, read, update, and delete managed status and dropdown columns via the API. Learn more here!
query {
managed_column (state: active) {
created_by
revision
settings {
...on StatusColumnSettings {
type
labels {
id
description
}
}
}
}
}