Recent searches
No recent searches
API updates for update_many and for single tickets should be the same
Posted Oct 27, 2022
Currently you can update certain areas of a ticket using the update_many API endpoint
PUT /api/v2/tickets/update_many.json?<ticket_id>
but not when updating a ticket using the single ticket API endpoint
PUT /api/v2/tickets/{ticket_id}
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.
2
2
2 comments
Erica Girges
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.
Best,
Erica
0
Asaf Max
Hello Erica,
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
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.
0