REST API returns 403 Forbidden when creating nonconformance records programmatically

PLM Windchill
, , , , , , , ,
1

I’m working on automating quality event creation through the REST API but consistently hitting a 403 Forbidden error when trying to create nonconformance records. The REST API ACL configuration seems correct at first glance, but there’s clearly something blocking programmatic creation.

Here’s the API call that’s failing:

POST /Windchill/servlet/odata/ProdMgmt/Nonconformances
{
  "Number": "NC-2025-001",
  "Description": "Supplier defect",
  "Severity": "High"
}

The same user credentials work fine in the UI for creating nonconformances manually. I’ve verified the user has Creator role in the Quality context, but the API still rejects the request. The custom attribute permissions might be involved since we have several required fields on our nonconformance object model.

Has anyone dealt with REST API permission issues specific to quality management objects? The nonconformance object model has some custom lifecycle gates that might be interfering.

system 2

I’ve worked through this exact scenario multiple times. Here’s the comprehensive solution addressing all three critical areas:

1. REST API ACL Configuration

The 403 error stems from insufficient type-level permissions. Navigate to Site > Utilities > Access Control and verify your REST API user or role has explicit Create grant on the Nonconformance object type. Context-level permissions aren’t sufficient - you need type-level grants:


Object Type: wt.quality.Nonconformance
Principal: [Your REST API User/Role]
Permission: Create (Grant)

Critically, also check the parent Quality Management context ACL to ensure no Deny rules are cascading down.

2. Custom Attribute Permissions

This is the most common culprit. Open Type and Attribute Management, select your Nonconformance type, and for EACH custom attribute:

  • Security tab: Verify Modify permission is granted (not inherited with restrictions)
  • Advanced tab: Ensure ‘Include in REST API’ is checked
  • Validation tab: Confirm no cross-attribute dependencies require UI-only fields

Required attributes need explicit Modify grants. If any required attribute has conditional visibility or permissions based on lifecycle state, the REST creation will fail at initial state.

3. Nonconformance Object Model Specifics

The nonconformance object model has unique requirements:

// Your payload needs these minimum fields:
{
  "ContainerReference": "/Windchill/servlet/odata/ProdMgmt/Containers('OR:wt.pdmlink.PDMLinkProduct:12345')",
  "Number": "NC-2025-001",
  "Description": "Supplier defect",
  "Severity": "High",
  "LifeCycleState": "INWORK"
}

Key points:

  • ContainerReference must point to valid Quality container OID
  • LifeCycleState must match initial state from lifecycle template
  • If your model has custom IBA attributes, include them with proper type casting

Verification Steps:

  1. Test with minimal payload (only required OOTB fields) to isolate custom attribute issues
  2. Enable verbose REST logging: log4j.logger.wt.rest=DEBUG in log4j.properties
  3. Check MethodServer.log for actual permission denial details
  4. Verify REST user can create other quality objects (like Quality Events) to rule out general quality context issues

Common Gotcha in 11.1:

If you have workflow processes attached to nonconformance creation, ensure the REST user has Execute permission on the workflow template. Some organizations restrict workflow initiation to UI users, causing REST creation failures.

After implementing these changes, restart method server and test with a minimal payload first, then gradually add custom attributes to identify any problematic fields. The 403 should resolve once all three areas are properly configured.

This draft is based on general Windchill knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.

3

The 403 on nonconformance creation usually indicates ACL issues at the object type level rather than context permissions. Check if your REST API user has explicit Create permission on the Nonconformance type itself in the ACL editor. Quality objects often have stricter type-level ACLs that override context roles.

4

I ran into something similar last year. The nonconformance object model in 11.1 has some quirks with programmatic access. You need to check two things: First, verify that all required custom attributes have proper API access flags set in the type manager. Second, make sure your API payload includes the container reference - nonconformances need explicit context binding even if your user has default context set. Try adding ContainerReference to your JSON payload pointing to the Quality container OID.

5

Good point about the container reference. I added it but still getting 403. I checked the type-level ACLs and the REST user does have Create permission on Nonconformance type. However, I noticed we have three custom attributes marked as required during creation. Could the custom attribute permissions be blocking this even if type-level access is granted?

barb3137 6

Tested this on Windchill 12.1 and confirming the type-level Create grant on wt.quality.Nonconformance was the missing piece resolving our 403 errors.

7

Yes, custom attribute permissions absolutely can cause 403 errors that aren’t obvious. Go to Type and Attribute Management, find your Nonconformance type, and check each custom attribute’s Security tab. If any required attribute has ‘Deny’ or restricted Modify permission for your API user’s role, the entire creation will fail with 403. Also verify the attributes have ‘Include in REST’ checkbox enabled - we had cases where attributes were visible in UI but not exposed to API.

8

Adding to the attribute discussion - check if your nonconformance object model has any validation rules or constraints defined at the type level. In 11.1, certain validation rules execute during REST creation but fail silently with generic 403 instead of proper validation errors. We saw this with cross-attribute dependencies where one required field’s value depended on another. The REST API couldn’t resolve the dependency chain and threw 403 instead of a meaningful validation message.

9

Check your method server logs when the 403 occurs. Enable debug logging for wt.method.MethodServerServlet and wt.rest components. The actual permission denial reason often gets logged there even when the API response is generic. Also verify your REST API configuration file has proper authentication realm settings for quality objects.