We’re encountering a persistent ‘permission denied’ error when attempting to update account records via the REST API. The error occurs specifically when modifying certain custom fields that were recently added to our account module.
API call:
PUT /crm/v3/Accounts/{record_id}
Authorization: Zoho-oauthtoken {token}
{"Custom_Field_1": "value"}
Error response:
HTTP 403: Permission Denied
{"code": "PERMISSION_DENIED", "message": "insufficient privileges"}
The same API user can successfully update standard fields like Account Name and Industry, but fails on custom fields. We’ve verified the OAuth scope includes ZohoCRM.modules.accounts.UPDATE. Our recent org restructure involved changes to role hierarchy and field-level permissions. The API integration user is assigned to a custom profile. Has anyone dealt with field-level permission conflicts after role changes?
I’ve seen this exact scenario. The issue is that role hierarchy changes can shift which roles have implicit access to fields. Even if the API user’s profile has permissions, the role position matters. One workaround is to create a separate ‘API Integration’ role at the CEO level with full field access, then assign your integration user to that role. This isolates API permissions from your regular user hierarchy changes.
Update: I found a field dependency rule on Custom_Field_1 that restricts editing based on the Account Owner’s role. This was added during the restructure and wasn’t documented. Removing that dependency resolved the immediate issue, but we still need the business logic.
Thanks for the suggestion. I checked the field permissions and the custom fields show as ‘Read/Write’ for the profile. However, I noticed the fields have a ‘Role-based visibility’ setting enabled. Could this be overriding the profile permissions even though the API user technically has a role assigned?
Another aspect to verify: check if the custom fields have any validation rules or field dependencies that might be triggering permission checks. Sometimes fields are configured with ‘Edit based on criteria’ rules that evaluate the user’s role or profile. These can block API updates even when basic permissions look correct. Review the field properties under ‘Field Permission’ and ‘Validation Rules’ sections.
Role-based visibility can definitely cause this. When you enable role-based field visibility, the field becomes visible only to specific roles in the hierarchy, regardless of profile permissions. If your API user’s role isn’t in the allowed roles list for those fields, API calls will fail with permission errors. This is a common gotcha after org restructures. Navigate to the field settings and check the ‘Visible to Roles’ configuration. You might need to add the API user’s role to the allowed list, or consider creating a dedicated integration role at the top of your hierarchy that has access to all fields needed for API operations.
Check if the API user’s profile has explicit field-level permissions for those custom fields. After role hierarchy changes, field permissions don’t always cascade automatically. Go to Setup > Users and Control > Security Control > Field Permissions and verify the custom fields are accessible to the API user’s profile.