REST API returns 403 Forbidden when creating nonconformance records with custom attributes in quality management

PLM Windchill
, , , , , , , ,
1

We’re building automation to create nonconformance records through the Windchill REST API but consistently hitting 403 Forbidden errors. The API call works fine for creating standard parts and documents, but fails specifically for quality objects.

Our service account has full Quality Administrator role in the UI and can manually create nonconformance records without issues. The REST API ACL configuration appears correct at first glance, but something’s blocking the programmatic creation.

We’ve verified custom attribute permissions are set, and the nonconformance object model shows the correct access policies. Has anyone encountered similar permission issues with quality management objects via REST API?


POST /Windchill/servlet/odata/QualityMgmt/Nonconformances
Response: 403 Forbidden
Error: "Insufficient permissions to create object"
2

Good catch on the validators. I’d also verify the API payload includes all required custom attributes for nonconformance creation.

3

Thanks both. I checked the Access Control policies and found the issue - the Nonconformance type had an additional ACL entry that wasn’t visible in the role permissions. It required explicit membership in a “Quality Data Creator” group that wasn’t documented anywhere in our setup.

4

Let me provide a complete solution addressing all three focus areas:

REST API ACL Configuration: The 403 error stems from layered security checks. You need to configure ACLs at multiple levels:

  1. Navigate to Site > Utilities > Access Control
  2. Find “Nonconformance” object type
  3. Add explicit CREATE permission for your service account or create a dedicated “API Service Accounts” group
  4. Verify the container (Product/Library) also grants CREATE rights

Custom Attribute Permissions: Quality objects often have mandatory custom attributes with their own permission model:


// Check attribute-level security in type manager
TypeDefinition nonconformType = TypeHelper.getType("Nonconformance");
for (AttributeDefinition attr : nonconformType.getAttributes()) {
    // Verify each required attribute allows WRITE access
}

Nonconformance Object Model: The object model requires specific context and relationship data:


POST /Windchill/servlet/odata/QualityMgmt/Nonconformances
{
  "name": "NCR-2025-001",
  "description": "Surface defect",
  "container": "/Products/MainProduct",
  "responsibleParty": "user:qualityeng",
  "severity": "HIGH",
  "affectedPart": {"id": "OR:wt.part.WTPart:12345"}
}

Key differences from UI creation:

  • API requires explicit container path (UI infers from context)
  • ResponsibleParty must use “user:” or “group:” prefix
  • AffectedPart needs full object reference, not just number
  • All required custom attributes must be in payload

Validation: After ACL fixes, test with minimal payload first, then add attributes incrementally. Enable REST API logging (wt.rest.debug=true) to see exact permission check failures. If issues persist, check for custom lifecycle validators that might block programmatic creation - these are visible in Type and Attribute Management under the Nonconformance type definition.

5

I’ve seen this before with quality objects. The 403 typically means the ACL is checking at the object type level, not just role level. Check if your service account has explicit CREATE permission on the Nonconformance type itself in the Access Control policies.