The Java HTTP client bombs out with a 422 Unprocessable Entity when I push the version tag matrix to /api/v2/data-actions/{id}/versions.
I’m constructing the payload with action ID references and diff summary directives, but the schema validation pipeline rejects it before the atomic PUT even lands.
{ "actionId": "8a1b2c3d-4e5f-6789-0abc-def123456789", "versionTag": "v2.1.0", "backwardCompatible": true }
Retention limits don’t matter here since the repo only holds three tags, yet the semantic version increment trigger fires correctly and the response just dumps version_schema_mismatch. The audit logs sit blank anyway.
{
"actionId": "8a1b2c3d-4e5f-6789-0abc-def123456789",
"versionNumber": 2,
"complianceMetadata": {
"retentionPolicy": "MiFID_II_ARCHIVE",
"legalHold": true,
"securePauseDirective": false
}
}
Audit requirements dictate that all Data Action version updates must include explicit retention parameters. The 422 response triggers when the payload omits the mandatory compliance metadata block. Dodd-Frank 15c3-1 and MiFID II Article 16 both require immutable version tracking for any policy modification. The endpoint rejects diff summary directives because they bypass the legal hold validation. Replace the nested array with the structure above. Set legalHold to true if the action modifies any recording retention rules.
Check the gateway logs. You’ll see the schema validator drop the request immediately.
[ERROR] validation.service: field 'complianceMetadata' is required for version bump ...
Just a fragment. The rest gets truncated by the SIEM filter.
Keep the Content-Type header strict. The Java client sometimes appends charset parameters that break the parser. Retention must default to 2555 days for MiFID II archives. The secure pause directive belongs in the WFM quality module, not here. That’s for PCI masking on live channels anyway. Leave it out. Version bumps fail when the audit trail isn’t explicitly declared.