Problem Definition

The Automation public REST API (POST /rest/v1/rule, PUT /rest/v1/rule/{uuid}, PUT /rest/v1/rule/{uuid}/state) always runs full content validation on rule components, regardless of the rule's state. The Automation UI and the internal rule-save endpoint both defer this validation until a rule is enabled - a DISABLED rule with incomplete/empty required fields saves successfully through either of those paths.

This inconsistency means any rule that already exists on a site in a disabled, incomplete state cannot be recreated or updated through the public API. For example, each of the following is accepted by the UI/internal API when the rule is DISABLED, but rejected with an HTTP 400 by the public API:

• Link work items action with linkType: "" > 400 "Please select a valid link type and provide a work item to link to."
• Delete comment action with commentId missing > 400 "Comment action must contain a comment"
• Work item created trigger with eventKey/issueEvent missing > 400 "Rule trigger value of 'null' is not valid for event trigger."
• Add comment action with comment: "" > 400 "Comment action must contain a comment"
• Transition work item action with destinationStatus: null > 400 "Please select a valid destination status (also ensure the app user has access in this space)."

This also affects updates that only change metadata of an existing incomplete rule, since the update call re-validates the entire rule body. It particularly blocks integrations that create, update, or migrate automation rules between sites via the public API — a disabled, incomplete rule that was legitimately saved on a source site cannot be reproduced on a target site through the same, documented API.

Suggested Solution

Align the public API's validation behavior with the UI and internal API: skip full content validation for rules saved with state: DISABLED, applying it only when a rule is being saved as (or transitioned to) ENABLED. As an alternative or complement, expose an explicit opt-out (for example, a validate=false request parameter) that callers can use when saving disabled rules, so validation can still be requested explicitly if desired.