199e748e27be Thanks for your reply, this fixed our issue. We did sent the idUuid, but an invalid one. It was formerly ignored, but now indeed it is checked, no longer just the technical ID in the URL.

093de162ef35 try adding idUuid to the payload of the changes you push. It was not required, and now it is required. Broke our integration. As you mentioned, I hope as well that it is part of the changes planned for this ticket

Good to see progress on this item.

We use the internal API's to update Automation Rules for now, but since a week or so this is broken. Is this due to changes that you are pushing to support this feature? We understand that you have no support for internal api's, but it would be nice if we could swap over to the supported version once you're done.

We used to use URL's like:
https://<INSTANCE NAME>.atlassian.net/gateway/api/automation/internal-api/jira/<SITEID>/pro/rest/<PROJECTID>/rule/<RULEID>

To get and push changes to rules. Is there an ETA for when management of AutomationRules via API's is publicly (or privately) available?

This is obviously really important for any organisation > 5 projects and while we are waiting for this Atlassian rolls out fancy new icons...

Just a thought .... which I should have posted ages ago .....

Certainly in some cases, e.g. integration with CI/CD pipelines security tokens are included as part of the web request. The risk is of course that by having a download and then storing in an SCM then the security token could be exposed. Whilst it could be argued that the contents could be covered by a .gitignore then this partially negates the benefit in having a download facility. Perhaps an additional element is to mask specific query parms for web requests in any download process.  

I appreciate that this may be seen as an additional product enhancement request. 

I’d like to strongly endorse the addition of a public REST API for Automation rules—one that supports both exporting and importing JSON definitions. By exposing this functionality via API, we unlock powerful capabilities that go far beyond a manual UI import:

• Git-backed version control: Store your rule definitions in a GitHub repo to track every change, revert to prior versions, and correlate rule updates with code changes or Jira issue commits.

• Automated CI/CD pipelines: Leverage existing CI tools (GitHub Actions, Jenkins, etc.) to automatically validate, test, and deploy rule changes across multiple projects or environments—eliminating manual steps and reducing human error.

• Peer review & auditability: Treat automation rules as code: open PRs for new or updated rules, have teammates review the JSON before merging, and maintain a clear audit trail of who changed what and why.

• Backup & disaster recovery: Regularly pull all rule definitions via the API and store them off-site, ensuring you can quickly restore or replicate your automations in case of data loss.

• Cross-project consistency: Use scripts to push standardized rule libraries to dozens of projects at once, guaranteeing uniform behavior without painstaking manual setup.

In short, a true REST API for Automation rules would transform them from siloed UI artifacts into first-class “infrastructure as code.” Please consider this enhancement to empower teams with modern DevOps practices for managing their Jira automations.