Please give a quick overview of your product feature request or feedback and note who in your organization is affected by this issue [ex. agents, admins, customers, etc.] (2-3 sentences)
I am requesting that the Zendesk API provide a specific error response (e.g., 403 Forbidden) instead of a 200 OK when an update to a custom user field is blocked by the new role-based permissions. This currently impacts our System Administrators and Integrations Team who manage automated user data synchronization.
What problem do you see this solving? (1-2 sentences)
The core issue is a "silent failure" in the API. When an API request attempts to update a restricted field, Zendesk returns a success status even though the change was ignored. This makes it impossible for automated systems to detect that data was not saved, leading to critical data inconsistencies between our internal systems and Zendesk.
When was the last time you were affected by this lack of functionality, or specific tool? What happened? How often does this problem occur and how does this impact your business? (3-4 sentences)
This issue occurs daily across our automated workflows. Because the API reports a success, our integration logs show no errors, but the actual user records remain outdated. This forced us to spend hours troubleshooting "ghost" issues where data simply didn't appear in user profiles despite "successful" logs.
Are you currently using a workaround to solve this problem? (If yes, please explain) (1-2 sentences)
Currently, the only way to ensure updates are successful is to use an API key with full administrative access. This is a significant security concern as it forces us to bypass the "least-privilege" principle. We want to use restricted roles for security, but we cannot do so reliably if the API doesn't provide feedback on failed updates.
What would be your ideal solution to this problem? How would it work or function? (1-2 sentences)
Ideally, if a field update is rejected due to permissions, the API should return a 403 Forbidden or a 422 Unprocessable Entity. If the request is a bulk update, the 200 OK response should include a specific error object in the JSON body (e.g., "field_id_123": "permission_denied") so we can programmatically handle the failure.