REST API callback fails on approval status update with 401 error after workflow action in approval management

PLM Windchill
, , , , , , , ,
1

We’re experiencing 401 Unauthorized errors when our external system tries to update approval statuses via REST API callbacks. The workflow triggers correctly and our OAuth2 token works for initial requests, but fails specifically when the approval action completes.

Our callback endpoint receives the notification, but when we try to update the approval status back in Windchill, we get:


HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer realm="Windchill"
{"error": "invalid_token"}

The token handling seems fine for other operations, and we’ve verified the service account has approval management permissions. The issue appears related to API endpoint security during workflow state transitions. Has anyone encountered token validation issues specifically during approval callbacks?

2

I ran into this exact issue last quarter. The solution involves three key areas:

OAuth2 Token Handling in Workflow Context: Your service account needs workflow.execute scope in addition to approval.write. Update your OAuth2 client configuration:


scope=approval.read approval.write workflow.execute
grant_type=client_credentials

API Endpoint Security: Workflow callbacks require explicit service account identification. Modify your API call:


Authorization: Bearer {access_token}
X-PTC-ServiceAccount: workflow_service
X-PTC-WorkflowContext: true

Service Account Permissions: The service account must have these ACL entries:

  • ApprovalAdministrators group membership
  • WorkflowAdministrator role on the affected context
  • Execute permission on the specific workflow template

Verify the workflow template ACL:


GET /Windchill/servlet/odata/ProdMgmt/Workflows('{workflow_id}')/AccessControl

The X-PTC-WorkflowContext header is critical - it tells Windchill to evaluate the request within the workflow security context rather than as a standard API call. Without it, even valid tokens fail during state transitions because Windchill can’t determine which workflow instance authorized the callback.

Also add retry logic with exponential backoff. Occasionally, workflow state transitions take a few seconds to commit, and immediate callback attempts can hit a race condition where the approval object is still locked by the workflow engine.

3

Also worth checking token expiration timing. Workflow callbacks can take several minutes depending on system load, and if your token has a short TTL, it might expire between the workflow trigger and the callback execution. We increased our token lifetime to 3600 seconds and implemented refresh token logic to handle long-running workflows. The 401 during approval actions specifically suggests the token is valid but lacks workflow-specific permissions.

4

Thanks for the suggestions. I verified the token scope includes approval.write and the service account is in ApprovalAdministrators. Token expiration is set to 7200 seconds, so that shouldn’t be the issue. The strange part is that the same token works for querying approval status but fails on updates. Could there be different security contexts for read vs write operations during workflow callbacks?

5

Yes, absolutely. Windchill applies stricter security validation for state-changing operations during active workflows. The approval update endpoint requires not just approval.write scope but also workflow.execute permissions. Additionally, if your workflow has custom security labels or access control policies, those are enforced even for service accounts. Check your workflow definition for any security validators that might be rejecting the API call.