Tickets are the means through which your end users (customers) communicate with agents in Zendesk Support. Tickets can originate from a number of channels, including email, Help Center, chat, phone call, Twitter, Facebook, or the API. All tickets have a core set of properties.

Zendesk has both a Tickets API and a Requests API. A ticket is an agent's perspective on a ticket. A request is an end user's perspective on a ticket. End users can only see public comments and certain fields of a ticket. Therefore, use the Requests API to let end users view, update, and create tickets. Use the Tickets API described in the rest of this document to let agents and admins manage tickets.

Every ticket has a requester and submitter. The user who is asking for support through a ticket is the requester. For most businesses that use Zendesk Support, the requester is a customer, but requesters can also be agents in your Zendesk Support instance.

The submitter is the user who created a ticket. By default, the requester of a ticket is the submitter. For example, if your customer emails your support address, this creates a ticket with the customer as both the requester and submitter. The requester will also appear as the author of the ticket's first comment.

However, a support agent can also create a ticket on behalf of a customer. If an agent creates a ticket through the web interface, the agent is set as the submitter. This can be accomplished equivalently through the API by passing the agent's user ID as the submitter_id when creating a ticket. In this case, the agent, who is the submitter, becomes the author of the ticket's first comment and the ticket shows that the agent created the ticket "on behalf of" the customer.

In the description above, we see that a ticket's first comment author can differ depending on who created the ticket. In both examples, whomever is the submitter becomes the first comment author. This will hold true for all tickets created in Zendesk Support with one exception.

Exception: If the ticket is created as a follow-up ticket (i.e., if the ticket is created using via_followup_source_id), then any submitter_id attribute is ignored. The API sets whoever created the follow-up ticket (for the API, always the authenticated user) as the first comment author.

When creating a ticket, use the comment property to set the ticket description, which is also the first comment. Example:

{"ticket": {"subject": "My printer is on fire!", "comment": {"body": "The smoke is very colorful."}}}

Important: Do not use the description property to set the first comment. The property is for reading purposes only. While it's possible to use the property to set the first comment, the functionality has limitations and is provided to support existing implementations.

Tickets in Zendesk Support can be passed to a group of agents unassigned, or to a specific agent in a specific group. A ticket can only be assigned to one assignee at a time.

Aside from the requester, a ticket can include other people in its communication, known as collaborators or cc's. Collaborators receive email notifications when tickets are updated. Collaborators can be either end users or agents.

All tickets in Zendesk Support start out as New and progress through Open, Pending, Solved, and Closed states. A ticket must have an assignee in order to be solved.

Tickets are represented as JSON objects with the following properties:

You can also include a comment_count property in the JSON objects returned by GET requests by sideloading it. Example:

GET /api/v2/tickets.json?include=comment_count

{
  "id":               35436,
  "url":              "https://company.zendesk.com/api/v2/tickets/35436.json",
  "external_id":      "ahg35h3jh",
  "created_at":       "2009-07-20T22:55:29Z",
  "updated_at":       "2011-05-05T10:38:52Z",
  "type":             "incident",
  "subject":          "Help, my printer is on fire!",
  "raw_subject":      "{{dc.printer_on_fire}}",
  "description":      "The fire is very colorful.",
  "priority":         "high",
  "status":           "open",
  "recipient":        "[email protected]",
  "requester_id":     20978392,
  "submitter_id":     76872,
  "assignee_id":      235323,
  "organization_id":  509974,
  "group_id":         98738,
  "collaborator_ids": [35334, 234],
  "follower_ids":     [35334, 234], // This functionally is the same as collaborators for now.
  "problem_id":       9873764,
  "has_incidents":    false,
  "due_at":           null,
  "tags":             ["enterprise", "other_tag"],
  "via": {
    "channel": "web"
  },
  "custom_fields": [
    {
      "id":    27642,
      "value": "745"
    },
    {
      "id":    27648,
      "value": "yes"
    }
  ],
  "satisfaction_rating": {
    "id": 1234,
    "score": "good",
    "comment": "Great support!"
  },
  "sharing_agreement_ids": [84432]
}

GET /api/v2/tickets.json

Returns a maximum of 100 tickets per page. See Pagination.

Tickets are ordered chronologically by created date, from oldest to newest. The first ticket listed may not be the absolute oldest ticket in your account due to ticket archiving. To get a list of all tickets in your account, use the Incremental Ticket Export endpoint.

For more filter options, use the Search API.

You can also sideload related records with the tickets. See Side-Loading.

Archived tickets are not included in the response. See About archived tickets in the Support Help Center.

• Agents

The following endpoints are also available:

GET /api/v2/organizations/{organization_id}/tickets.json

GET /api/v2/users/{user_id}/tickets/requested.json

GET /api/v2/users/{user_id}/tickets/ccd.json

GET /api/v2/users/{user_id}/tickets/assigned.json

GET /api/v2/tickets/recent.json

ccd lists tickets that the specified user is cc'd on.

recent.json lists tickets that the requesting agent recently viewed in the agent interface, not recently created or updated tickets (unless by the agent recently in the agent interface).

The query parameter is not supported for this endpoint. Use the Search API to narrow your results with query.

curl https://{subdomain}.zendesk.com/api/v2/tickets.json \
  -v -u {email_address}:{password}

Status: 200 OK

{
  "tickets": [
    {
      "id":      35436,
      "subject": "Help I need somebody!",
      ...
    },
    {
      "id":      20057623,
      "subject": "Not just anybody!",
      ...
    },
    ...
  ]
}

GET /api/v2/tickets.json?external_id={external_id}

Returns an array of one or more tickets.

External ids don't have to be unique for each ticket. As a result, the request may return multiple tickets with the same external id.

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets.json?external_id={external_id} \
  -v -u {email_address}:{password}

Status: 200 OK

{
  "tickets": [
    {
      "id":      35436,
      "subject": "Help I need somebody!",
      ...
    },
    {
      "id":      20057623,
      "subject": "Not just anybody!",
      ...
    },
    ...
  ]
}

GET /api/v2/tickets/{id}.json

Returns a number of ticket properties though not the ticket comments. To get the comments, use List Comments.

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets/{id}.json \
  -v -u {email_address}:{password}

Status: 200 OK

{
  "ticket": {
    "id":      35436,
    "subject": "My printer is on fire!",
    ...
  }
}

GET /api/v2/tickets/show_many.json?ids={ids}

Accepts a comma separated list of ticket ids to return.

This endpoint will return up to 100 tickets records.

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets/show_many.json?ids=1,2,3 \
  -v -u {email_address}:{password}

See Listing Tickets

POST /api/v2/tickets.json

Takes a "ticket" object that specifies the ticket properties. The only required property is "comment". See Ticket Comments. All writable properties listed in JSON Format are optional.

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets.json \
  -d '{"ticket": {"subject": "My printer is on fire!", "comment": { "body": "The smoke is very colorful." }}}' \
  -H "Content-Type: application/json" -v -u {email_address}:{password} -X POST

Status: 201 Created
Location: https://{subdomain}.zendesk.com/api/v2/tickets/{id}.json

{
  "ticket": {
    "id":      35436,
    "subject": "My printer is on fire!",
    ...
  }
}

{
  "ticket": {
    "subject":  "My printer is on fire!",
    "comment":  { "body": "The smoke is very colorful." },
    "priority": "urgent"
  }
}

Note: Submitting a ticket with HTML data will not result in the HTML being stripped out.

An audit object is generated and included in the response when you create a ticket. The audit object has an events array listing all the updates made to the new ticket. For more information, see Ticket Audits. You can also add your own metadata to the audit object. See Setting metadata.

"audit": {
    "events": [
      {
        "id": 206091192907,
        "type": "Create",
        "field_name": "subject",
        "value": "My printer is on fire!"
      },
      {
        "id":206091192547,
        "type": "Comment",
        "body": "The smoke is very colorful.",
        ...
      }
      ...
    ]
  }
}

Once a ticket is closed (as distinct from solved), it can't be reopened. However, you can create a new ticket that references the closed ticket. To create the follow-up ticket, include a via_followup_source_id parameter that specifies the closed ticket. Example:

curl https://{subdomain}.zendesk.com/api/v2/tickets.json \
  -d '{"ticket": {"via_followup_source_id": 103, "comment": {"body": "My printer is still too hot!"}}}' \
  -v -u {email_address}:{password} -X POST -H "Content-Type: application/json"

The parameter only works with closed tickets. It has no effect with other tickets.

By default, the first comment author is the authenticated user making the API request. To set a different author, include an author_id property in the comment object.

Ticket creation can sometimes take a while because of complex business rules. Asynchronous creation allows you to get the response back quickly and queues a background job to do the actual work.

To make an asynchronous request, simply add the parameter async in your request.

POST api/v2/tickets.json?async=true

As soon as the request is received, it returns a 202 Accepted. The response includes the new ticket id with a job_status JSON object. However, you may not be able to fetch the ticket until the job is done.

Note: Some ticket id numbers may get skipped if ticket creation fails.

POST /api/v2/tickets/create_many.json

Accepts an array of up to 100 ticket objects.

• Agents

{
  "tickets": [
    {
      "subject":  "My printer is on fire!",
      "comment":  { "body": "The smoke is very colorful." },
      "priority": "urgent"
    },
    {
      "subject":  "Help",
      "comment":  { "body": "This is a comment" },
      "priority": "normal"
    }
  ]
}

curl https://{subdomain}.zendesk.com/api/v2/tickets/create_many.json \
  -d '{"tickets": [{"subject": "My printer is on fire!", "comment": { "body": "The smoke is very colorful." }}, {"subject": "Help!", "comment": { "body": "Help I need somebody." }}]}' \
  -H "Content-Type: application/json" -v -u {email_address}:{password} -X POST

This endpoint returns a job_status JSON object and queues a background job to do the work. Use the Show Job Status endpoint to check for the job's completion.

PUT /api/v2/tickets/{id}.json

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets/{id}.json \
  -H "Content-Type: application/json" \
  -d '{"ticket": {"status": "open", "comment": { "body": "The smoke is very colorful.", "author_id": 494820284 }}}' \
  -v -u {email_address}:{password} -X PUT

Status: 200 OK

{
  "ticket": {
     "id":      35436,
     "subject": "My printer is on fire!",
     "status":  "open",
     ...
  },
  "audit": {
     "events": [...],
     ...
  }
}

The PUT request takes one parameter, a ticket object that lists the values to update. All properties are optional.

{
  "ticket": {
    "comment": { "body": "Thanks for choosing Acme Jet Motors.", "public": true },
    "status":  "solved"
  }
}

An audit object is generated and included in the response when you update a ticket. The audit object has an events array listing all the updates made to the ticket. If your update does not change the ticket, an audit won't be created and included in the response. For more information, see Ticket Audits. You can also add your own metadata to the audit object. See Setting metadata.

"audit": {
    "events": [
      {
        "id": 2060476287,
        "type": "Change",
        "field_name": "priority",
        "value": "normal",
        "previous_value": "low"
      }
    ]
  }
}

PUT /api/v2/tickets/update_many.json

PUT /api/v2/tickets/update_many.json?ids={ids}

Accepts an array of up to 100 ticket objects, or a comma-separated list of up to 100 ticket ids.

• Agents

To make the same change to multiple tickets, use the following endpoint and data format:

https://{subdomain}.zendesk.com/api/v2/tickets/update_many.json?ids=1,2,3

{
  "ticket": {
    "status": "solved"
  }
}

To make different changes to multiple tickets, use the following endpoint and data format:

https://{subdomain}.zendesk.com/api/v2/tickets/update_many.json

{
  "tickets": [
    { "id": 1, "status": "solved" },
    { "id": 2, "status": "pending" }
  ]
}

Batch updates are automatically safe and fail when there's another update to the same tickets after the job started. See Protecting against ticket update collisions

You can use the bulk update format to add or remove tags to the tag list of each ticket without overwriting the existing tags. To do so, include the additional_tags or remove_tags property in the ticket object. Example:

curl https://{subdomain}.zendesk.com/api/v2/tickets/update_many.json?ids=1,2,3 \
  -d '{"ticket": {"additional_tags":["a_new_tag"]}}' \
  -H "Content-Type: application/json" \
  -v -u {email_address}:{password} -X PUT

The additional_tags or remove_tags properties only work with bulk updates, not batch updates.

curl https://{subdomain}.zendesk.com/api/v2/tickets/update_many.json?ids=1,2,3 \
  -H "Content-Type: application/json" \
  -v -u {email_address}:{password} -X PUT \
  -d '{"ticket": {"status": "solved"}}'

curl https://{subdomain}.zendesk.com/api/v2/tickets/update_many.json \
  -H "Content-Type: application/json" \
  -v -u {email_address}:{password} -X PUT \
  -d '{"tickets": [{"id": 1, "status": "solved"}, {"id": 2, "status": "pending"}]}'

This endpoint returns a job_status JSON object and queues a background job to do the work. Use the Show Job Status endpoint to check for the job's completion.

To protect against collisions when updating or bulk updating tickets, set the safe_update property to true and include an updated_stamp in your request. See Request body. The ticket will only be updated if the updated_stamp datetime value you specified matches or is more recent than the last recorded ticket update (in other words, matches or is more recent than the ticket's updated_at value).

When updating a single ticket, the response code will indicate if the ticket was successfully updated.

{
  "ticket": {
    "subject":"Updated Subject",
    "updated_stamp":"2015-10-14T16:53:51Z",
    "safe_update":"true",
    ...
  }
}

If the updated_stamp property does not match or is earlier than the updated_at datetime value for the ticket, the update operation will fail and an "UpdateConflict" error response will be sent.

Status: 409 Conflict
{
   "description": "Safe Update prevented the update due to outdated ticket data.
                   Please fetch the latest ticket data and try again.",
   "error": "UpdateConflict"
}

When bulk updating tickets, individual ticket objects can also use the safe_update and updated_stamp properties.

If any tickets in the bulk operation fail to update due to the updated_stamp property not matching or being earlier than the ticket's updated_at datetime value, an "UpdateConflict" error response will be returned in the Job Status.

Batch updates are automatically safe and fail when there's another update to the same tickets after the job started.

{
  "tickets": [
    {
      "id":"9999",
      "subject":"Ticket 9999 Subject Update",
      "updated_stamp":"2015-10-14T16:58:42Z",
      "safe_update":"true"
    },
    {
      "id":"10",
      "subject":"Ticket 10 Subject Update",
      "updated_stamp":"2015-09-24T21:52:46Z",
      "safe_update":"true"
    }
  ]
}

Example Job Status safe update error response

{
  "job_status": {
    "results": [
      {
        "index": 0
        "error": "UpdateConflict",
        "id": 9999,
        "details":"Safe Update prevented the update due to outdated ticket data. Please fetch the latest ticket data and try again."
      }
    ],
    ...
  }
}

PUT /api/v2/tickets/{id}/mark_as_spam.json

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets/{id}/mark_as_spam.json \
  -v -u {email_address}:{password} -X PUT -d '{}' -H "Content-Type: application/json"

Status: 200 OK

PUT /api/v2/tickets/mark_many_as_spam.json?ids={ids}

Accepts a comma-separated list of up to 100 ticket ids.

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets/mark_many_as_spam.json?ids=1,2,3 \
  -v -u {email_address}:{password} -X PUT -d '{}' -H "Content-Type: application/json"

This endpoint returns a job_status JSON object and queues a background job to do the work. Use the Show Job Status endpoint to check for the job's completion.

POST /api/v2/tickets/{id}/merge.json

Merges one or more tickets into the ticket with the specified id.

See Merging tickets in the Support Help Center for ticket merging rules.

Any attachment to the source ticket is copied to the target ticket.

• Agents

Agents in the Enterprise account must have merge permissions. See Creating custom roles and assigning agents (Enterprise) in the Support Help Center.

The request takes a data object with the following properties:

The comments are optional but strongly recommended.

Comments are private and can't be modified in the following cases: * Any of the sources or target tickets are private * Any of the sources or target tickets were created through Twitter, Facebook or AnyChannel In any other case, comments default to private but can be modified with the comment privacy parameters.

Example

{
  "ids": [123, 456, 789]
  "target_comment": "Combining with #123, #456, #789",
  "source_comment": "Closing in favor of #111"
}

curl https://{subdomain}.zendesk.com/api/v2/tickets/{id}/merge.json \
  -v -u {email_address}:{password} -X POST \
  -d '{"ids": [123, 456, 789], "source_comment": "Closing in favor of #111", "target_comment": "Combining with #123, #456, #789"}' \
  -H "Content-Type: application/json"

This endpoint returns a job_status JSON object and queues a background job to do the work. Use the Show Job Status endpoint to check for the job's completion.

GET /api/v2/tickets/{id}/related.json

The request returns a data object with the following properties:

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets/{id}/related.json \
  -v -u {email_address}:{password}

Status: 200 OK

{
  "topic_id": null,
  "followup_source_ids": [],
  "jira_issue_ids": [],
  "from_archive": false,
  "incidents": 7,
  "twitter": {
    "handle_id": 10,
    "profile": {
      "created_at": "2013/01/08 23:24:49 -0800",
      "description": "Zendesk is the leading ...",
      ...
    },
    "direct": false
  }
}

Note: If the CCs and Followers feature is enabled for the account, using email CCs and followers is preferred. See Setting email CCs and Setting followers. You can still set collaborators with the collaborators and additional_collaborators ticket properties described in this section. They'll automatically make end users CCs and agents followers.

When creating or updating a ticket, you can set collaborators on a ticket using one of three properties: collaborator_ids, collaborators or additional_collaborators. The collaborators property provides more flexibility, as outlined below.

An email notification is sent to the collaborators when the ticket is created or updated.

Setting collaborators or collaborator_ids when updating a ticket replaces existing collaborators. Make sure to include existing collaborators in the update request if you want to retain them on the ticket. If you only want to add more collaborators, use additional_collaborators instead.

The collaborator_ids property is a basic option that takes an array of user ids.

{
  "ticket": {
    "collaborator_ids": [562624, 624562, 243642]
  }
}

The collaborators property is a more flexible option. It takes an array consisting of a combination of user ids, email addresses, or objects containing a name and email property.

• 562562562
• "[email protected]"
• { "name": "Someone Special", "email": "[email protected]" }

Use an object to create the user on the fly with the appropriate name in Zendesk Support.

{
  "ticket": {
    "collaborators": [ 562, "[email protected]", { "name": "Someone Else", "email": "[email protected]" } ]
  }
}

The additional_collaborators property is used to add additional collaborators. It preserves the existing collaborators, and adds new collaborators to the ticket. It takes an array consisting of a combination of user ids, email addresses, or objects containing a name and email property.

{
  "ticket": {
    "additional_collaborators": [ 562, "[email protected]", { "name": "Someone Else", "email": "[email protected]" } ]
  }
}

Even if you use the collaborators property, the JSON response will specify the new or updated collaborators as an array of user ids in the collaborator_ids property. The response doesn't have a collaborators property.

When creating or updating a ticket, you can set followers on a ticket using the followers property.

An email notification is sent to the followers when the ticket is created or updated.

The followers property takes an array of objects representing agents. Each object must have an identifier, either user ID (user_id) or email address (user_email). If a user_email or user_id is given which doesn't exist in the account, that user object is ignored. Additionally, the action key can be set to either "put" or "delete" to indicate whether the user should be added to or removed from the followers list. If the action key is not given, the default value is "put".

{
  "ticket": {
    "followers": [
      { "user_id": "562624", "action": "put" },
      { "user_id": "624562" },
      { "user_id": "243642", "action": "delete" },
      { "user_id": "562", "user_email": "[email protected]", "action": "delete" },
      { "user_email": "[email protected]", "action": "put" },
    ]
  }
}

When creating or updating a ticket, you can set email CCs on a ticket using the email_ccs property.

A single email notification is sent to the requester and CCs when the ticket is created or updated, depending on trigger settings.

The email_ccs property takes an array of objects representing users. Each object must have an identifier, either user ID (user_id) or email address (user_email). If an email address is specified and the user doesn't exist in the account, a new user is created. Additionally, the key action can be set to either "put" or "delete" to indicate whether the user should be added to or removed from the email CCs list. If the action key is not given, the default value is "put". Optionally, if a new user is created, you can specify user_name to set the new user's name. If the user is implicitly created and a user_name is not given, the user name is derived from the local part of the email address. If an email address not associated with a user is included (for example, with the intention to implicitly create the user), but the value of the action key is "delete", that email address is not be created or added as an email CC.

A ticket can only have 48 email CCs. If more than 48 email CCs are included in the request, a "400 Bad Request" will be returned. If existing email CCs and the additional email CCs added through the request add up to more than 48, the email CCs will be truncated to 48 and no error will be reported.

Email CCs will not be updated if an internal note is also added to the ticket in the same update.

{
  "ticket": {
    "email_ccs": [
      { "user_id": "562624", "action": "put" },
      { "user_id": "243642": "action": "delete" },
      { "user_email": "[email protected]", "user_name": "Someone Else", "action": "put"}
    ]
  }
}

When you create or update a ticket, an Audit gets generated if the ticket properties have changed. On each such audit, you can add up to 1 kilobyte of custom metadata. You can use this to build your own integrations or apps. Note: If your update does not change the ticket, this will not create an Audit and will not save your metadata.

{
  "ticket": {
    "metadata": { "time_spent": "4m12s", "account": "integrations" },
    "comment":  { "body": "Please press play on tape now" },
    "status":   "pending"
  }
}

Note that metadata can only be set as part of other regular ticket updates as they are associated to a such rather than just the ticket. Zendesk Support also adds metadata on each ticket update, and the resulting audit JSON structure looks like this:

{
  "audit": {
    "id":         35436,
    "ticket_id":  47,
    "created_at": "2012-04-20T22:55:29Z",
    "author_id":  35436,
    "metadata": {
      "custom": {
        "time_spent": "4m12s",
        "account": "integrations"
      },
      "system": {
        "ip_address": "184.106.40.75",
        "location": "United States",
        "longitude": -97,
        "latitude": 38,
        "client": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3)"
      }
    },
    "via": {
      "channel": "web"
    },
    "events": [
      {
        "id":          1564245,
        "type":        "Comment"
        "body":        "Please press play on tape now",
        "public":      true,
        "attachments": []
      },
      ...
    ]
  }
}

When creating and updating tickets, you may attach files by passing in an array of the tokens received from uploading the files. For the upload attachment to succeed when updating a ticket, a comment must be included.

To get the token of an upload, see the Attachments section on uploading files.

The upload tokens are single use only. After a token is used to attach a file to a ticket comment, that token cannot be used to attach the same upload to an additional ticket comment.

{
  "ticket": {
    "comment":  { "body": "Please press play on tape now", "uploads":  ["vz7ll9ud8oofowy"] }
  }
}

You can specify a requester when creating a ticket. A name, email, and locale id can be set for the requester. A name and email are required. For locale ids, see the Locales API.

{
  "ticket": {
    "subject":   "Hello",
    "comment":   { "body": "Some question" },
    "requester": { "locale_id": 8, "name": "Pablo", "email": "[email protected]" }
  }
}

If the requester's identity doesn't exist in Zendesk, a new user profile is created on the user's behalf. The user needs to verify their identity to view his or her requests.

If a user exists in Zendesk with the specified email address, then Zendesk uses that user and makes no updates to existing users during the ticket creation process. In this approach, only the email attribute is required.

To set the value of one or more custom fields in a ticket, specify an array of objects consisting of id and value properties. For text or numeric fields, specify text or numbers for the value property:

 "custom_fields": [{"id": 25356371, "value": "I bought it at Buy More."}, ...]

For date fields, specify only the date (formatted as a ISO 8601 string) and omit the time:

 "custom_fields": [{"id": 25356634, "value": "2020-02-24"}, ...]

For fields with values defined by tags, such as drop-down lists, specify the option's tag name for the value property, not the option text displayed in the list. For example, if the option's display text is "HD 3000 color printer" and its tag is hd_3000, set the custom field's value as follows:

  "custom_fields": [{"id": 21938362, "value": "hd_3000"}]

Multi-select field values are also defined by tags. However, the value property is a comma-separated list. For example, if the values of the tags are hd_3000 and hd_5555, the custom field's values is as follows:

  "custom_fields": [{"id": 21938362, "value": ["hd_3000", "hd_5555"]}]

For more information, see Ticket Fields.

{
  "ticket": {
    "subject": "Hello",
    "comment": { "body": "Some question" },
    "custom_fields": [{ "id": 34, "value": "I need help!" }]
  }
}

DELETE /api/v2/tickets/{id}.json

• Admins
• Agents with permission to delete tickets

Agent delete permissions are set in Support. See Deleting tickets in the Support Help Center.

You can delete 400 tickets every 1 minute using this endpoint. The rate limiting mechanism behaves as described in Rate limits in the API introduction. Zendesk recommends that you obey the Retry-After header values. To delete many tickets, you may use Bulk Delete Tickets.

curl https://{subdomain}.zendesk.com/api/v2/tickets/{id}.json \
  -v -u {email_address}:{password} -X DELETE

Status: 204 No Content

DELETE /api/v2/tickets/destroy_many.json?ids={ids}

Accepts a comma-separated list of up to 100 ticket ids.

• Admins
• Agents with permission to delete tickets

Agent delete permissions are set in Support. See Deleting tickets in the Support Help Center.

curl https://{subdomain}.zendesk.com/api/v2/tickets/destroy_many.json?ids=1,2,3 \
  -v -u {email_address}:{password} -X DELETE

Status: 200 OK

GET /api/v2/deleted_tickets.json

Returns a maximum of 100 deleted tickets per page. See Pagination.

The results includes all deleted (and not yet archived) tickets that have not yet been scrubbed in the past 30 days. Archived tickets are not included in the results. See About archived tickets in the Support Help Center.

The tickets are ordered chronologically by created date, from oldest to newest. The first ticket listed may not be the oldest ticket in your account due to ticket archiving.

• Agents

curl https://{subdomain}.zendesk.com/api/v2/deleted_tickets.json \
  -v -u {email_address}:{password}

Status: 200 OK

{
 "deleted_tickets": [
   {
     "id": 581,
     "subject": "Wombat Party",
     "actor": {
         "id": 3946,
         "name": "Taz Wombat"
       },
     "deleted_at": "20140704T15:37:04Z",
     "previous_state": "open"
   }
 ],
 "next_page": null,
 "previous_page": null,
 "count": 1
}

PUT /api/v2/deleted_tickets/{id}/restore.json

• Agents

curl https://{subdomain}.zendesk.com/api/v2/deleted_tickets/{id}/restore.json -X PUT -v -u {email_address}:{password}

Status: 200 OK

PUT /api/v2/deleted_tickets/restore_many?ids={ids}

• Agents

curl https://{subdomain}.zendesk.com/api/v2/deleted_tickets/restore_many?ids={ids} -X PUT -v -u {email_address}:{password}

Status: 200 OK

DELETE /api/v2/deleted_tickets/{id}.json

Permanently deletes a soft-deleted ticket. See Soft delete in the Zendesk GDPR docs. To soft delete a ticket, use the Delete Ticket endpoint.

This endpoint enqueues a ticket deletion job and returns a payload with the jobs status.

If the job succeeds, the ticket is permanently deleted. This operation can't be undone.

• Agents

curl https://{subdomain}.zendesk.com/api/v2/deleted_tickets/{id}.json \
  -X DELETE -v -u {email_address}:{password}

Status: 200 OK
{
  "job_status" : {
     "status" : "queued",
     "progress" : null,
     "url" : "https://example.zendesk.com/api/v2/job_statuses/d4239ba02d5f0132c0b2600308a8421a.json",
     "id" : "d4239ba02d5f0132c0b2600308a8421a",
     "total" : null,
     "results" : null,
     "message" : null
  }
}

DELETE /api/v2/deleted_tickets/destroy_many?ids={ids}

Permanently deletes up to 100 soft-deleted tickets. See Soft delete in the Zendesk GDPR docs. To soft delete tickets, use the Bulk Delete Tickets endpoint.

This endpoint accepts a comma-separated list of up to 100 ticket ids. It enqueues a ticket deletion job and returns a payload with the jobs status.

If one ticket fails to be deleted, the endpoint still attempts to delete the others. If the job succeeds, the tickets that were successfully deleted are permanently deleted. This operation can't be undone.

• Agents

curl https://{subdomain}.zendesk.com/api/v2/deleted_tickets/destroy_many.json?ids=1,2,3 \
  -X DELETE -v -u {email_address}:{password}

This endpoint returns a job_status JSON object and queues a background job to do the work. Use the Show Job Status endpoint to check for the job's completion.

Status: 200 OK
{
  "job_status" : {
     "status" : "queued",
     "progress" : null,
     "url" : "https://example.zendesk.com/api/v2/job_statuses/d4239ba02d5f0132c0b2600308a8421a.json",
     "id" : "d4239ba02d5f0132c0b2600308a8421a",
     "total" : null,
     "results" : null,
     "message" : null
  }
}

GET /api/v2/tickets/{id}/collaborators.json

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets/{id}/collaborators.json \
  -v -u {email_address}:{password}

Status: 200

{
  "users": [
    {
      "id": 223443,
      "name": "Johnny Agent",
      ...
    },
    {
      "id": 8678530,
      "name": "Peter Admin",
      ...
    }
  ]
}

GET /api/v2/tickets/{id}/followers

Returns any users who follow the ticket.

The CCs and Followers feature must be enabled in Zendesk Support.

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets/{id}/followers \
  -v -u {email_address}:{password}

Status: 200

{
  "users": [
    {
      "id": "223443",
      "name": "Johnny Agent",
      ...
    },
    {
      "id": "8678530",
      "name": "Peter Admin",
      ...
    }
  ]
}

GET /api/v2/tickets/{id}/email_ccs

Returns any users cc'd on the ticket.

The CCs and Followers feature must be enabled in Zendesk Support.

If the feature is not enabled, the default CC functionality is used. In that case, use List Collaborators to list the users cc'ed on the ticket.

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets/{id}/email_ccs \
  -v -u {email_address}:{password}

Status: 200

{
  "users": [
    {
      "id": "223443",
      "name": "Johnny Agent",
      ...
    },
    {
      "id": "8678530",
      "name": "Peter Admin",
      ...
    },
    {
      "id": "6748530",
      "name": "Jane End User",
      ...
    }
  ]
}

GET /api/v2/tickets/{id}/incidents.json

• Agents

curl https://{subdomain}.zendesk.com/api/v2/tickets/12345/incidents.json \
  -v -u {email_address}:{password}

Status: 200 OK

{
  "tickets": [
    {
      "id":          33,
      "subject":     "My printer is on fire",
      "description": "The fire is very colorful.",
      "status":      "open",
      ...
    },
    {
      "id":          34,
      "subject":     "The printer is on fire over here too",
      "description": "The fire is very colorful as well!",
      "status":      "pending",
      ...
    },
  ]
}

GET /api/v2/problems.json

• Agents

curl https://{subdomain}.zendesk.com/api/v2/problems.json \
  -v -u {email_address}:{password}

The response is always ordered by updated_at, in descending order

Status: 200 OK

{
  "tickets": [
    {
      "id":          33,
      "subject":     "My printer is on fire",
      "description": "The fire is very colorful.",
      "status":      "open",
      ...
    },
    {
      "id":          34,
      "subject":     "The printer is on fire over here too",
      "description": "The fire is very colorful as well!",
      "status":      "pending",
      ...
    },
  ]
}

POST /api/v2/problems/autocomplete.json?text={name}

Returns tickets whose type is "problem" and whose subject contains the string specified in the text parameter.

You can specify the text parameter in the request body rather than the query string. Example:

{"text": "fire"}

• Agents

curl https://{subdomain}.zendesk.com/api/v2/problems/autocomplete.json?text=fire \
  -X POST -H "Content-Type: application/json" \
  -u {email_address}:{password}

Status: 200 OK

{
  "tickets": [
    {
      "id":          33,
      "subject":     "My printer is on fire",
      "description": "The flames are very colorful.",
      "type":        "problem",
      ...
    },
    {
      "id":          34,
      "subject":     "The printer is on fire over here too",
      "description": "The flames are very colorful as well!",
      "type":        "problem",
      ...
    },
  ]
}