In Zendesk Support, an authenticated admin can make API requests on behalf of any end user. The end user's email doesn't need to be verified. If a record is created, updated, or deleted, the change is associated with the end user, not the admin.
Making requests on behalf of end users consists of the following steps:
Related articles
Obtaining an OAuth access token with an impersonate scope
-
If not already done, create an OAuth client in Zendesk Support (Admin > API > OAuth Clients).
-
When requesting or creating the OAuth access token, specify an "impersonate" scope.
Example when creating the access token with the API:
curl https://{subdomain}.zendesk.com/api/v2/oauth/tokens.json \ -H "Content-Type: application/json" \ -d '{"token": {"client_id": "your_client_id", "scopes": ["impersonate", "write"]}}' \ -X POST -v -u {email_address}:{password}
Only admins can use the API to create OAuth access tokens.
Example when sending a user to the authorization page in an authorization flow:
https://z3napi.zendesk.com/oauth/authorizations/new?client_id=my_test_client&scope=impersonate+write&response_type=code
Making the request
Only Zendesk Support admins can make requests on behalf of end users.
-
In your request, use the access token to set an "Authorization" header. cURL example:
-H "Authorization: Bearer 8b56769914d4c38617a389cab95124042c3c3eadf3f66d5dc9d7df2a7bca21e2"
-
Set a "X-On-Behalf-Of" header that specifies either the user's username (the user's email address), or user ID. Examples:
-H "X-On-Behalf-Of: customer@example.com"
or
-H "X-On-Behalf-Of: 203427634"
Example request
curl https://z3napi.zendesk.com/api/v2/tickets/1/satisfaction_rating \
-H "Authorization: Bearer 8d56769914d4a38617a389cab90524042c3c3ebdf3f66d5dc9d7df2a7bca21e2" \
-H "X-On-Behalf-Of: customer@example.com" \
-H "Content-Type: application/json" \
-X POST \
-d '{"satisfaction_rating": {"score": "good", "comment": "Awesome support."}}'
The example adds a satisfaction rating to the ticket.
Note: The Create Satisfaction Rating endpoint only works on tickets with a status of Solved, or on tickets that were reopened after being solved. The endpoint doesn't work on tickets with a status of Closed or on archived tickets. For more information, see What's the difference between a solved ticket and a closed ticket.
8 Comments
not working
API Request
curl https://{SUBDOMAIN}.zendesk.com/api/v2/tickets/XXXX/satisfaction_rating \
-H "Authorization: Bearer {FULL_TOKEN} \
-H "X-On-Behalf-Of: {EMAIL_ADDRESS}
-X POST \
-d '{"satisfaction_rating": {"score": "good", "comment": "Awesome support."}}'
error response:
{
"error": {
"title": "Forbidden",
"message": "You do not have access to this page. Please contact the account owner of this help desk for further help."
}
}
Hi indra,
The CSAT endpoint only works on tickets with a status of Solved (or reopened after being Solved). Make sure the status of the ticket is not Closed or Archived. Some info on the different statuses:
Closed tickets are locked. They cannot be reopened or updated in any way.
https://support.zendesk.com/hc/en-us/articles/203660386-What-is-the-difference-between-a-Solved-ticket-and-a-Closed-ticket-
Hi,
I want to add comments on behalf of end users, according to docs I should just set up author_id
but when I refresh the comments I see my (I am admin) user id as author_id. I've tried this article and I am able to add a coment with different author using the X-On-Behalf-Of header but there are two still two issues:
Please how to add comments on behalf of end users?
Thanks
Regards,
Vojtech
Hello Vojtech -- the behavior you're experiencing is correct.
Regarding impersonation...
When using the X-On-Behalf-Of header, you can only impersonate end users. More details are here:
Making API requests on behalf of end users
"impersonate" is one of the available scopes that a token may have but it only allows admins to impersonate end users:
"...allows Zendesk Support admins to make requests on behalf of end users"
Regarding troubleshooting CORS...
If you're using the Zendesk Apps framework, make the request using the framework's client.request method with cors:true setting. That keeps your request coming from the same domain and avoids CORS issues (assuming you're not crossing over to another Zendesk instance).
The reason the request works server-side and not client-side is because CORS is only a browser based convention. Server-side apps don't have a CORS-like concept, so don't have such constraints. The same would be true if you're making the call using cURL (not a browser, so no CORS constraints).
Post back for more detail or if you run into issues.
I am attempting to update a ticket via the Support Tickets API endpoint using a token, impersonating an end-user. The request works, but any placeholders I add do not work. For instance, the following JSON request body:
Does not fill the placeholders. It just adds the placeholder as plain-text, like so:
If I replace the author ID with the ID of a user with role Agent or above, placeholders work fine.
It seems that end-users don't have permission to use placeholders. Is there any way for me to allow end-users to use placeholders?
For use-case, I have a Python-based local app that performs many automations for our Zendesk Support instance and places comments in tickets for any automatic actions taken. I want to use a "bot" end-user as the commenter for all of these comments for many important reasons (mostly metrics).
EDIT: Interestingly, the following placeholder does work
Hi Sam. As you discovered, there are limitations on what end users can pull. Usually these can be inferred by looking at the related API -- in the below case, user information. The documentation, for example, for GET /api/v2/users/{id}.json is limited to agents.
Since you're using a custom app, you could perhaps retrieve and cache that information through an agent authenticated call, then inline it into the subsequent call (versus using place holders). This doesn't avoid using an agent license as you mentioned, however.
@... Thanks for the quick reply!
I suspected this was the case. Do you know of any doc set I can view that will allow me to infer what placeholders a user might have access to? Possibly the Requests API?
I may just make a quick test that puts all available placeholders from the reference material in one comment, just to see what populates.
The closest I can offer is to find the corresponding API (such as the one in my previous comment) and see what restrictions it may have. In this API's case, it is restricted to agents. And in truth, end-user allowed API calls are very limited. You can search on "Allowed For" and "End Users" in the API documentation. For example, see this link: https://developer.zendesk.com/rest_api/docs/support/requests#list-requests
Please sign in to leave a comment.