Extend REST API Custom Object PUT Fails With Misleading 403 Insufficient Permissions
What it means
An Extend app calls the REST API to update a custom object that extends Worker. GET requests work fine, but PUT requests fail with a 403 insufficient-permissions error even though the calling user's security group and domain permissions all look correct. The error text points at security, but the real problem is the HTTP method and endpoint shape.
Troubleshooting
- Confirm the endpoint being called for the write. PUT expects a full, specific resource path identifying exactly which instance to update; if the payload is being sent to a general collection-style endpoint, PUT is the wrong verb for that shape.
- Re-check the security group and domain configuration only after ruling out the method/endpoint mismatch. Many users chase security settings first because the 403 text mentions permissions, but the same misconfigured request fails identically regardless of how permissive the security setup is.
- Switch to the object's getExtrapath-style endpoint with updateIfExists=true in the payload instead of the specific-instance PUT path, and let the server resolve where to write rather than specifying an exact address yourself.
- Re-test with a GET first to confirm the object and field identifiers in the payload match what the API actually returns, since a mismatched identifier in a POST payload can also surface as a permissions-flavored error.
Change the request from PUT against a specific resource path to POST against the object's getExtrapath endpoint with updateIfExists=true in the payload, letting Workday determine the target instance.
Standardize custom-object write integrations on the POST plus updateIfExists pattern rather than PUT to a hardcoded instance path, and document that a 403 on a write (with working GETs) is not automatically a security-configuration problem, check the HTTP method and endpoint shape before touching security groups or domains.