Jack

Have you tried setting ticket.custom_status_id with the custom status id of Athena Reply?

Can you post an example of your JSON payload?

The only way to differentiate between system fields and custom fields is to look at the “type” property, once you have seen the type of all the default system fields you can make a note of them and ignore them in your code, you could also combine that with the “removable” property, system fields are not removable so this will always be false for system fields (but it’s also false for some fields installed by apps, such as the linked ticket app)

Ideally you would have some sort of function that can run either on a schedule (cron job) if your database will be updated with new values you want to appear regularly or a function that is triggered when the database is updated. 

The code in the function would include a way to get the data you want from the database (maybe included as an event to the function or maybe a call to your database to get the necessary data) 

Then it would just be a case of updating your target custom fields potential values.

// Get data from database or function event

// If necessary transform data into a format we can use with the Zendesk API

let formattedData = [
{
  "name": "Option 1",
  "value": "value_for_option_1"
}
...more options here
]

// Send this as a PUT request to yoursubdomain.zendesk.com/api/v2/ticket_fields/{ticket_field_id}

Worth knowing that updating a custom fields options this way will overwrite them so if you have existing options on a ticket field and only want to append these new options from your database you will need to fetch the ticket field before you update it and merge the old options and new options.

This is the approach I would take to accomplish such a task.

Ah ok! 

I believe the problem is that you are not including the "trigger" parameter that the request requires, try this: 

{

"trigger":{

"title":"Test trigger",

"active":true,

"conditions":{

"all":[

{

"field":"current_tags",

"value":"wunderkind",

"operator":"includes"

}

]

},

"actions":[

{

"field":"notification_webhook",

"value":[

"abc",

"123"

]

}

]

}

}

My mistake, I think maybe it’s because your conditions do not have any operators? Please see this docs page for examples on creating or updating triggers https://developer.zendesk.com/documentation/ticketing/reference-guides/conditions-reference/

You need to also specify any conditions, you correctly have “all” conditions, I think maybe an empty array for “any” would fix this.

Trying to enable CSAT on a fresh trial account results in "Failed to update satisfaction settings" when trying to save changes - is this expected behaviour?

You can use the search API to find all tickets by status

You are creating a user and expecting it to show up in user fields? I am confused, you should POST a user field to the user_fields endpoint and then it will show up when you send a GET request to the user_fields endpoint