nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Automation Rule Management API is now Generally Available!

Scott Bell

Hi Atlassian Community,

In our previous post we announced our new Rule Management APIs available for testing. Today we’re excited to announce that the Automation Rule Management API has graduated from Early Access and is now Generally Available (GA) for all customers! 🎉

This release brings new capabilities for managing automation at scale, making it easier than ever for admins and developers to programmatically control rule configurations across your Jira sites

What’s new in GA?

Developer documentation updated: Find the latest API details, usage patterns, and best practices in our developer documentation.
Create connections via API: You can now create connections directly through the API, enabling more seamless integration with external systems.
Create new labels on the fly: When creating or updating rules, you can now specify new labels that will be created automatically if they don’t already exist.
Specify rule UUIDs: When creating a rule, you can provide a UUID. If it’s not already taken, it will be used for your new rule, making migrations and imports much simpler.

How does it work?

Here are some practical API use cases and examples to help you get started:

Import/Export a Rule

Export a rule using the “get a rule by UUID” API:

curl --request GET \
  --url '{baseSiteURL}/gateway/api/automation/public/jira/{cloudid}/rest/v1/rule/{ruleUuid}' \
  --header 'Accept: application/json' \
  --header 'Authorization: {authorisationToken}'

To import (clone) a rule, remove the uuid field from the payload if importing into the same site, then use:

curl --request POST \
  --url '{baseSiteURL}/gateway/api/automation/public/jira/{cloudid}/rest/v1/rule' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: {authorisationToken}' \
  --data '{ ... }'

Bulk Update Rule Scope

To update the scope of multiple rules (e.g., after creating a new project):

Search for rules by scope:

curl --request POST \
  --url '{baseSiteURL}/gateway/api/automation/public/jira/{cloudid}/rest/v1/rule/summary' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: {authorisationToken}' \
  --data '{ "scope": "ari:cloud:jira:{cloudId}:project/10001" }'

Update rule scope for each rule:

curl --request PUT \
  --url 'https://api.atlassian.com/automation/public/{product}/{cloudid}/rest/v1/rule/{ruleUuid}/rule-scope' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: {authorisationToken}' \
  --data '{ "ruleScopeARIs": [ "ari:cloud:jira:{cloudId}:project/10001", "ari:cloud:jira:{cloudId}:project/{newProjectId}" ] }'

Update Rules in Bulk

To update a set of rules (e.g., after a field rename):

Search for rules by trigger:

curl --request POST \
  --url '{baseSiteURL}/gateway/api/automation/public/jira/{cloudid}/rest/v1/rule/summary' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --header 'Authorization: {authorisationToken}' \
  --data '{ "trigger": "jira.incoming.webhook" }'

For each rule, fetch details, edit as needed, and update:

curl --request PUT \
  --url 'https://api.atlassian.com/automation/public/{product}/{cloudid}/rest/v1/rule/{ruleUuid}' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '{ "rule": {updatedRuleConfig} }'

Get Started

Check out the developer documentation for how to get started.

We want your feedback!

Have questions or want to share how you’re using the API? Drop your thoughts in the comments below. Your feedback helps us shape future improvements.

Thanks for being part of the Atlassian Community!

Comments

Bill Sheboy

Hi @Scott Bell

Thank you for the updated information. I have a couple of questions:

What can you share on progress to create endpoints and webhooks for accessing automation audit logs?

While there is some older documentation for Data Center on component types and structure in rule JSON, there is nothing newer or for Cloud's Jira, Confluence, and JSM automation. As a result, customers must first create many example rules and analyze them to identify the content to use for endpoints to create / update rules. What can you share on plans to create such documentation to support using the endpoints?

Kind regards,
Bill

Scott Bell

@Bill Sheboy thanks for the reply and apologies for the late response.

We’re looking at the Audit Log soon. I don’t have concrete dates, but I want to make sure we have API endpoint coverage. If you can share your top audit use cases, we’ll add them to our requirements.

For the rule structure, I spoke with the engineering team. The public API documents the top-level rule object and data types. The tricky bit is component configs. Each component has its own payload and the component value field is component-specific. There are hundreds across Jira, Confluence and JSM, so we can’t publish a complete, stable schema right now.

The best method today is to create a sample rule with the component you need and review the export JSON to see the exact config. I know that’s not ideal at scale, and your feedback is noted.

Bill Sheboy

Thanks for the updates, @Scott Bell

And, I did much of that component analysis you describe when I created my own rule parser outside of Jira, and I agree it is a moving target due to the excellent, continuing improvements the team makes to automation :^)

For some audit log endpoint and webhook scenarios, I expect many are to add instrumentation to cover gaps in the rule list for monitoring and documentation. For example:

increase the history duration for available logs when read using the endpoints
improve the audit log details to add a "verbose" setting which shows all changes made to a rule for updates (This was one of my original automation suggestions in JAC, but it was replaced by team member edits :^)
given a set of rules filtered-by criteria (e.g., Status, enabled, scope, project, etc.), return all log entries for a specific timeframe
given a set of rules filtered-by criteria, return all log entries over a specified execution Duration (excluding stuff like the new Delay() action impacts)
for the above endpoints, include orderBy parameters
for the above endpoints, I would want to avoid the problems caused by ornery project admins locking down permissions, and thus add parameters to allow Site / Product Admins to override owner / editor permissions if you anticipate those would impact audit log access
add events to webhooks for rule creation, rule deletion, rule update, rule enable, rule disable, rule moved, rule scope changed, etc.

Thanks again, and kind regards,
Bill

Mykenna Cepek

(wrong account, see below)

Mykenna Cepek

I must be missing something. I'm excited about this API, but not finding what I was expecting.

The "previous post" link above (as of today) goes to an article that talks about the orchestration (advanced) components and doesn't mention the automation API. I think it should go here instead.

I understood that this API was to help with rule import and export (among other things). And many of us were particularly interested in doing full backups of all their rules periodically with this API.

But based on what I'm seeing for the API endpoints today, getting a usable full backup of all rules would involve:

Using GET /rule/summary repeatedly (since it's a paged call) to extract the UUIDs for all currently defined rules.
Iterating on those UUIDs and calling GET /rule/<UUID> to return the JSON for each rule.
Reformatting all those results into a single JSON that matches what we get when exporting all rules manually.

Otherwise you end up with a pile of separate rules (in our case, hundreds of them) which can be individually imported, or sent individually to PUT /rule to recreate them.

Instead of making all that extra work for all of us, wouldn't it have made sense to have one more GET endpoint returning all rules in the proper (importable) format, identical to what "export all rules" does today? I was excited. Now I'm just tired.

Nick Wade -Opus Guard-

@Scott Bell can you share any plans / Jira items to follow wrt 3LO and making this API usable in Forge apps? I ask because this seems like it may be an initial release with more follow-on needed:

Forge and OAuth2 apps cannot access this REST resource.

(from https://developer.atlassian.com/cloud/automation/rest/api-group-rule-management/#api-rest-v1-rule-summary-post )

Best, -nick wade
Co-founder and COO, Opus Guard
keep what you need, remove what you don't

Scott Bell

@Mykenna Cepek Good catch on the “previous post” link. I've fixed the link so it goes to the correct place now.

On backups, you’re right about the mechanics today. To take a full backup you call `GET /rule/summary` with paging to collect all rule IDs, then `GET /rule/{id}` for each one. This was a deliberate first step so responses are predictable given rule payload sizes vary a lot.

Two clarifications that should help:

You do not need to reformat responses. The JSON from `GET /rule/{id}` is compatible with `PUT /rule` for create or update.
For incremental backups, use summary to find what changed since your last run, then fetch only those IDs. Store a checkpoint of the last run so you can compare.

We recognise the value of a single bulk export that returns an import-ready bundle. I have captured that as a request for future planning.

Hope this helps,

Scott

Scott Bell

@Nick Wade -Opus Guard- No dates or public tickets to share but we are talking with the Forge team about OAuth2 right now

I will keep you posted as this progresses!

If you don't mind, could you share some of the use cases you would want to see enabled with this?

Thanks,

Scott

Mykenna Cepek

@Scott Bell - Thanks for the reply.

I hear that this is MVP. I think we'd agree that the hassle factor is currently high for fully backing up automation rules with this cool new API. I think we'd also agree that the ideal Disaster Recovery plan for automation rules would be to manually import a single JSON file of all the rules. Jira creates this today via "Export rules" in the Global Automation Admin screens.

Since this API can't do that, reformatting all the individually download JSON files (into a single JSON file) would be required. Otherwise one would need to import each downloaded rule, either via the API or manually in the UI. While technically feasible, it inflicts extra pain for a Jira Admin on the hot seat in a Disaster Recovery scenario.

Thanks for proactively adding this to be addressed in your backlog. I appreciate this progress!

Nick Wade -Opus Guard-

@Scott Bell the use cases for this API are just the basics, aren't they? So for our use cases, as an app admin I want my Forge app to be able to CRUD Automation Rules and/or manage/report them via the Automation Rule Management API. LMK if I'm missing something? Deeper use cases about why we want to do that have to do with the functionality of our apps (so far in our case, Content Retention Manager which you can take a look at on our website or the Atlassian Marketplace)

I suppose the others would be to trigger said rules in response to various conditions we detect (something also not possible from Forge apps today?) and have reasonable/workable limits for such

Scott Bell

@Mykenna Cepek we will be keeping this in mind as we look to improve the API further

Steffen Opel [Utoolity]

@Scott Bell - to add to Nick's comment: We're working on a "Automate with AWS" Forge app that provides various actions for advanced workflow automation via applicable AWS services like Lambda and Step Functions. The configuration of resp. demo scenarios can be a bit tedious for end users, so while we'll also document them of course,, being able to opt-in to configuring sample rules would considerably simplify and streamline the onboarding UX!

Ben Romberg - codefortynine

@Scott Bell to add use cases for Forge usage, we'd like to clone Jira Automation rules in our app Deep Clone for Jira. It allows to clone entire projects spaces and many customers have asked us to clone the space-scoped Automation rules as well.

Scott Bell

@Nick Wade -Opus Guard- yes you're right, the new endpoints are just the basics - we've got more we want to tackle over time.

As for Forge apps to be able to call the API - we are looking into this with the Forge team. I'll reach out when I have further details. CC @Steffen Opel _Utoolity_ @Ben Romberg - codefortynine

Kacper Tkacz

@Scott Bell Hello, would (and if - are there any timelines shared) this API be available through OAuth2 apps?

Scott Bell

@Kacper Tkacz heya - sorry still no timeline here. It's still on my radar. Will update further with more API developments (we've got a lot more to add)

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

confluence

jira

rest-api

api

jira-cloud

confluence-cloud

automation

devops

itsm

jira-service-management

jira-automation

jsm

cloud-automation