VerifyRule (V2) parity mapping

Supported in:

This guide details the request and response mapping specifications and property parity analysis for migrating from the legacy Backstory Rules Engine V2 API (VerifyRule) to the modern Chronicle API (VerifyRuleText).

Protocol and mapping overview

Feature Legacy API (VerifyRule V2) Modern Chronicle API (VerifyRuleText)
HTTP method POST POST
Permissions Partner token or legacy API keys chronicle.googleapis.com/rules.verifyRuleText

Request payload field-by-field parity

The modern Chronicle API request simplifies the input parameters: instead of wrapping YARA-L strings inside structured nested Rule objects, clients pass the raw rule_text directly to a target scoped instance parent.

Legacy field (VerifyRuleRequest / Rule) Modern field (VerifyRuleTextRequest) Field type Parity & migration notes
— instance (in HTTP path) string Google Cloud scoping context / new field: Scopes structural validation under target instances: projects/{project}/locations/{location}/instances/{instance_uuid}.
rule.rule_text rule_text string Renamed / restructured: Legacy passed the YARA-L rule contents nested inside a Rule message field (rule.rule_text). The modern API flattens this, taking the raw YARA-L contents directly via the required rule_text string parameter. Rename to ruleText in JSON.

Response payload field-by-field parity

Both APIs return validation results, with the modern API reporting granular diagnostics.

Legacy field (VerifyRuleResponse) Modern field (VerifyRuleTextResponse) Field type Parity & migration notes
success success bool Direct map: Boolean flag indicating query compile success.
compilation_error / context — string Retired / restructured: Plain string error output is replaced by the list of structured warnings and errors inside compilation_diagnostics.
— compilation_diagnostics repeated CompilationDiagnostic New field: Contains the detailed collection of compile warnings, info logs, and syntax errors generated by the YARA-L parser.

Key differences

  • Google Cloud project scoping integration:
    • Scoped natively under parent project instance folder bindings (instance path parameter).
  • Request flattening:
    • Rather than instantiating and transmitting nested Rule resource parameters, clients pass the raw YARA-L rule code strings directly inside the request rule_text field.
  • Structured warnings support:
    • Output details change from simple error strings (compilation_error) to structured warnings and syntax logs (compilation_diagnostics), helping engineers identify exact compile warnings.
  • IAM permissions:
    • Request validation maps to standard Cloud IAM permission validation check (chronicle.googleapis.com/rules.verifyRuleText).