Risk register API update fails with validation error on invalid risk score

QMS ETQ Reliance
, , , , , , , ,
1

We’re integrating our internal risk assessment tool with ETQ Reliance risk register via REST API. Updates work fine for most fields, but we’re hitting validation errors when trying to update risk scores programmatically.

The API call returns a 400 error with message “Invalid risk score value” even though the score (7.5) falls within our configured range (1-10). The same value updates successfully through the UI. We’ve verified the API authentication and field mappings are correct.

POST /api/v2/risk-register/RR-2024-089
{"riskScore": 7.5, "severity": "High"}
Response: 400 "Invalid risk score value"

I’m concerned our pre-integration validation isn’t catching something the API requires. Has anyone encountered similar validation mismatches between UI and API updates for risk scores?

2

I can provide a comprehensive solution based on your specific scenario. You’re hitting three interconnected issues that commonly affect risk score API updates in ETQ 2023.

Risk Score Validation Issue: The core problem is that ETQ’s REST API enforces strict integer validation for risk scores, regardless of UI configuration. Your 7.5 decimal value violates this constraint. The API schema definition takes precedence over form-level customizations.

API Error Handling Requirements: Implement robust pre-validation in your integration layer before making API calls:

// Pre-integration validation
function validateRiskScore(score, severity) {
  const roundedScore = Math.round(score);
  if (roundedScore < 1 || roundedScore > 10) return false;
  return {score: roundedScore, originalScore: score};
}

Integration Pre-checks Solution: Before each API update, perform these validation steps:

  1. Data Type Verification: Convert decimal scores to integers using proper rounding logic that aligns with your risk methodology
  2. Field Dependency Check: Verify that severity alignment matches ETQ’s risk matrix - High severity typically requires scores of 7-10
  3. Record State Validation: Query the risk record’s workflow state first. Use GET /api/v2/risk-register/RR-2024-089/state to confirm the record accepts direct updates
  4. Payload Structure: Include all required fields even if unchanged. ETQ’s validation sometimes fails when optional-but-expected fields are omitted:
POST /api/v2/risk-register/RR-2024-089
{
  "riskScore": 8,
  "severity": "High",
  "assessmentDate": "2025-03-15",
  "assessedBy": "integration_user"
}

Recommended Implementation Pattern: Create a validation middleware layer that:

  • Transforms decimal scores to integers with business rule-based rounding
  • Stores original decimal values in a custom “Calculated Risk Score” field for audit purposes
  • Validates severity-score alignment against your configured risk matrix
  • Logs all transformations for compliance tracking

This approach maintains data integrity while working within ETQ’s API constraints. If you need decimal precision for regulatory compliance, consider storing calculated scores in custom fields and using the integer score for workflow routing only.

The key is treating the API as the source of truth for data type requirements, not the UI configuration. Always validate against the API schema before submission.

3

Adding to the previous response - I encountered this exact issue last year. The problem is that ETQ’s risk scoring API validates against the base schema definition, not your customized form rules. Even though your UI configuration permits decimal scores through custom JavaScript validation, the underlying API still expects integers.

You have two options: modify your integration to round scores to integers before sending, or work with ETQ support to enable decimal precision in the API schema. We went with the first approach since it was faster to implement. Our integration now applies Math.round() to all risk scores before the API call, and we store the precise decimal value in a custom field for reference.

4

This is a common integration pitfall. The error message “Invalid risk score value” can be misleading because it doesn’t specify whether it’s a type mismatch, range violation, or dependency issue. I recommend enabling detailed API logging in ETQ (Admin > System Settings > API Logging) to get the full validation stack trace. That will tell you exactly which validation rule is failing. In my experience, about 60% of these cases are data type issues, 30% are missing required dependent fields, and 10% are actual range violations.

5

I’ve seen this before. ETQ’s API validation for risk scores is stricter than the UI. The API expects integer values only by default, even if your UI configuration allows decimals. Check your risk matrix configuration - there’s often a mismatch between what the form allows and what the API schema enforces.

6

Have you checked the API documentation for the specific version you’re using? ETQ 2023 introduced some changes to risk score handling. Also, verify that your severity field alignment matches - sometimes the validation error is actually triggered by a secondary field mismatch, not the risk score itself.