API updates for update_many and for single tickets should be the same
Currently you can update certain areas of a ticket using the update_many API endpoint
but not when updating a ticket using the single ticket API endpoint
It does not make sense that I can update a field value using update many and not the individual ticket endpoints.
For example, when updating a ticket using the tickets API, the instruction to add additional tags is being ignored when doing so for the single ticket endpoint but is accepted using the update_many endpoint.
Thanks for sharing your question with the Community! You should be able to make those property value updates using the individual ticket update endpoint. The only difference between Update Many Tickets and Update Ticket is that Update Many automatically checks for ticket update collisions. With Update Ticket, you would need to include those safe guards yourself to prevent conflicts. Have you tried making the Update Ticket request with those specifications? If not, you can see how to do that here.
Not according to the response I got in the support ticket. You can look at ZD ticket #10920595 for the details but here is the response I got from the agent
Currently, the documented and expected behaviour to update tags without replacing them on individual tickets, you can use the add tags endpoint to achieve this.
Otherwise, the update_many end-point can also be used to achieve the same if other attributes need to be updated.
I'm afraid this functionality is working as expected and not something that will be fixed, and would be considered a feature request.
I would need to use either the tags endpoint or the update_many for the tickets endpoint.
So it goes back to my original statement that if I am able to update the tags under the update_many endpoint for tickets, i should also be able to do so when updating the tickets endpoint on a specific ticket number. using the same payload
Right now your APIs are all over the place to where an update to the ticket ends up requiring multiple endpoints to be used.
Another such example is in creating schedules. Instead of creating the schedule with the initial time ranges, I would have to first create the schedule (which is created with a default time) and then run a second API request to update the time ranges.
The API for updating the schedule should be kept as is but the one to create in the first place should have the schedule time ranges included so as to not needing a second call.
The design is flawed.
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.