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.
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.
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.
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.
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?
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.