Zendesk HTTP Request

Estimated reading: 6 minutes 162 views

The Zendesk HTTP Request activity allows you to perform bulk operations through API requests, such as updating tickets, managing users, organizations, and groups, adding comments, and uploading or downloading attachments.

Why use HTTP Request instead of other Zendesk activities?

1. Work with multiple resources: Update or retrieve information for several tickets, users, or other objects in a single request.
2. Combine actions: Reduce the need to chain multiple activities by performing several operations in one step.
3. Access advanced API operations: Perform advanced actions not available in other Zendesk activities, such as:

a. Filtering results with query parameters (e.g., retrieve tickets from a specific organization with a defined tag).
b. Sending structured JSON payloads with nested fields, attachments, or conditional data.

4. Customize requests: Define the method type (GET, POST, PUT, DELETE), set headers, add query parameters, and configure the request body to match your requirements.

Properties

Configuration

Once you select the respective project where Zendesk has been authenticated, the activity will automatically retrieve the available connections for that project.

If no connection is added, click here to learn more.

The following properties are available after the project is integrated:

Zendesk: Indicates the account name associated with the integration.

Input

Request URL: *Specifies to provide the API endpoint (action-specific path) and it accepts values in “String” datatype. Refer the below documentation to learn more about Request URL.

Method: *Specifies to provide the HTTP method to be used when calling the API. Supported methods are:

GET – Retrieves or fetches records from categories such as tickets, users, organizations, etc.
POST – Creates a new resource such as a ticket or user.
PUT – Updates existing resources such as tickets, users, or comments.
DELETE – Removes existing resources such as tickets, users, or comments.
PATCH – Updates only specific fields in existing resources such as tickets or users.

Base URL: Automatically populated with the base URL from the activity.

Request Headers: Allows you to provide custom headers required by the API, such as authentication details or content type.

Query Parameters: Specifies to provide key and value pairs used as input parameters in the request URL. This field is required only with the GET method to filter, sort, or paginate results.

Body: Specifies the request payload. Accepts input in string format with JSON content.

MISC

Display Name: Displays the name of the activity. The activity name can be customized, which aids in troubleshooting.

SkipOnError: Specify the “Boolean” value as “True” or “False.”

True: Continue executing the workflow regardless of any errors thrown.
False: Halt the workflow if it encounters any errors.
None: If the option is left blank, the activity will, by default, behave as if “False” were chosen.

Version: It indicates the version of the feature being used.

OUTPUT

Response Body: Returns the response body from the API call as a String data type.

Response Headers: Returns the response headers as a Dictionary data type.

Response Status Code: Returns the execution status code of the API as an Integer data type. Each status code represents a different execution result.

Result: This parameter allows you to view the execution status of the activity and returns a value in “Boolean.”

True: Indicates that the activity has been executed successfully without any errors.
False: Indicates that the activity has been unsuccessful due to an unexpected error being thrown.

* Represents mandatory fields to execute the workflow.

Note

1. The base URL is predefined in the activity and cannot be edited or removed.

2. The “Body” field is not available for GET method calls. To filter or sort results, use the Query Parameters

3. Even if Skip on error is set to True/ false, and you are performing bulk updates where one resource is incorrect or fails, the request will still complete, return the status of the failed resource, and then continue to the next step in the workflow.

Common Status Codes

1. 200 – Success (request completed successfully)
2. 201 – Created (a new resource has been created, e.g., ticket or user)
3. 202 – Request accepted but processing is not yet complete.
4. 204 – No Content (request succeeded but no content returned, common with DELETE)
5. 400 – Bad Request (invalid input or request format)
6. 401 – Unauthorized (missing or invalid authentication)
7. 403 – Forbidden (insufficient permissions)
8. 404 – Not Found (resource doesn’t exist)
9. 500 – Internal Server Error (server-side issue).
10. 504 – Gateway Timeout – The server didn’t respond in time.
11. 503 Service Unavailable → API service is down or overloaded.

Request URL

This activity provides the base URL. Along with it, you need to specify the request URL, which varies depending on the resource (such as tickets, users, comments, etc.).

Examples:

POST – Create a new organization:

RequestURL: “/organizations.json”

Body: “{“”organization””:{“”name””:””sl org 200″”,””created_at””:””0001-01-01T00:00:00″”,””domain_names””:[],””organization_fields””:{},””shared_comments””:false,””shared_tickets””:false,””tags””:[],””updated_at””:””0001-01-01T00:00:00″”}}”

PUT / PATCH – Update an existing ticket:

RequestURL : “/tickets/ID.json”

Body: “{“”ticket””:{“”comment””:{“”body””:””tstein””,””uploads””:null,””public””:true,””author_id””:null}}}”

GET – Search for a user by email

RequestURL: “users/search.json?

query=email:user123@testng.com

Click here to refer detailed information on the official Zendesk API documentation.

Example using Zendesk HTTP request activity

In this example, we will demonstrate how to use the Zendesk HTTP Request activity to first create a new support ticket and then update the ticket with a follow-up comment. This is a common workflow where:

a. A user raises an issue (ticket creation).
b. Later, more details or updates need to be added to the same ticket (ticket update with comments).

Steps:

1. Drag and drop the Create Ticket activity into the workflow.
2. Enter the description “The user reports that they are unable to login with valid credentials.”
3. Provide the subject “ Unable to login to the website”.
4. In the output section, declare a variable in the Ticket ID parameter to capture the ticket ID returned from Zendesk.
5. Add a Write Log activity to print the ticket ID for reference.

Update the Ticket with Comments

6. Drag and drop the Zendesk HTTP Request activity after the Write Log activity.
7. Set the Method to PUT.
8. In the Request URL, enter: “tickets/” + TICKET_NUMBER + “.json”

(Here, TICKET_NUMBER refers to the variable holding the ticket ID from Step 1.)

9. In the Body parameter, provide the comment details:

“{“”ticket””:{“”comment””:{“”body””:””Totally 400 users were affected but right now the issue is resolved. Please provide the RCA.””,””uploads””:null,””public””:true,””author_id””:null}}}”

10. In the output section of the HTTP Request activity, declare a variable in the Response Status Code parameter to capture the execution result.
11. Add a Write Log activity to print the status code and verify whether the update was successful (200 indicates success).

Result:

a. A ticket is created in Zendesk with the given subject and description.
b. A follow-up comment is added to the same ticket with status code confirmation.

Zendesk HTTP Request

Why use HTTP Request instead of other Zendesk activities?

Properties

Note

Common Status Codes

Request URL

Examples:

Example using Zendesk HTTP request activity

Recently Viewed articles

Zendesk HTTP Request

CONTENTS