Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Jira Cloud’s Automation REST API lets you find rules, create and edit them, change their state or scope, and delete them when disabled. The documented endpoints use /rest/v1. Before building an integration, choose the correct Jira Cloud base path, confirm the caller’s permissions, and check that its app type is allowed to access the rule-management resources.
Check compatibility and choose a base path
These instructions apply to Jira Cloud. They are not instructions for Jira Data Center. Atlassian’s rule-management documentation says Forge and OAuth 2.0 apps cannot access the documented rule resources, including the rule and template operations described here. Verify that restriction against the current reference before choosing an integration architecture: Rule management API.
As an Amazon Associate I earn from qualifying purchases.
For Jira, substitute jira for {product} and your site’s cloud ID for {cloudid} in one of these documented base paths:
https://api.atlassian.com/automation/public/jira/{cloudid}https://{sitename}/gateway/api/automation/public/jira/{cloudid}
Atlassian documents API-token authentication through api.atlassian.com; the site gateway can also use browser session cookies. Authentication establishes who is making the request, but does not itself grant permission to manage rules. Authorization depends on the user’s relevant product-level permissions. See Atlassian’s Automation API introduction and base path guide.
#1 Best Overall
To discover the cloud ID, Atlassian points to the site’s /_edge/tenant_info endpoint. Use the cloud ID for the Jira site you intend to manage, not a value copied from an unrelated site.
Find a rule and retain its UUID
Rule summaries are useful when you need to locate a rule before retrieving its full configuration. The list endpoint supports cursor-based pagination and a limit:
GET /rest/v1/rule/summary
For filtered searches, use:
POST /rest/v1/rule/summary
The search body can filter by trigger, state, scope, author, and limit, and can include a cursor. Atlassian requires at least one of trigger, state, scope, or limit in a summary-search request. Summary results include metadata such as the rule name, state, scope, and UUID, along with pagination information. Keep the UUID for the next request; the summary is not the full editable rule.
Retrieve the full rule before editing
Fetch a rule by UUID to get its full representation:
GET /rest/v1/rule/{ruleUuid}
Use the returned structure as the basis for an update payload. In particular, preserve IDs for components that already exist. Atlassian says existing component IDs are required in an update; new components can be created and components can be deleted as needed. Avoid treating example component values or schema versions as universal defaults—the reference examples illustrate request shape, not a guaranteed production configuration.
Create a rule with a JSON payload
Create a rule by sending a JSON body to:
POST /rest/v1/rule
The request requires a rule object and a connections array. The rule object can include metadata and automation components; the reference example illustrates fields such as name, description, labels, state, actor, author account ID, rule scope ARIs, trigger, components, and write access type. Select values and component structures that are valid for the specific rule and current API schema rather than copying illustrative placeholders. A successful create is documented as 201 Created.
For the complete request and response schemas, use Atlassian’s rule-management reference.
Free tools Windows power users keep installed
One-click scans. No signup required.
Update a rule or change only its state or scope
Update the rule configuration
Use PUT /rest/v1/rule/{ruleUuid} with a rule payload and connections. Build that payload from the full rule retrieved by UUID, retaining identifiers for existing components so the service can distinguish them from newly added ones.
Enable or disable a rule
Use the dedicated state endpoint when the change is only whether the rule is active:
PUT /rest/v1/rule/{ruleUuid}/state
The body requires a value containing the rule state; ENABLED is one state example in the reference. Follow the current endpoint schema for the value you send.
Change the rule scope
Use PUT /rest/v1/rule/{ruleUuid}/rule-scope to change scope. Its request body requires ruleScopeARIs. This dedicated endpoint is preferable to a full configuration update when scope is the only intended change.
Recommended Free Tools
Delete a rule safely
The delete operation is documented for disabled rules:
DELETE /rest/v1/rule/{ruleUuid}
If the rule is enabled, disable it through the state endpoint first, then send the delete request. Do not assume deletion will remove an enabled rule.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Consider template-based creation
If the current template catalog contains a suitable starting point, Atlassian also documents POST /rest/v1/template/create. The request requires templateId and ruleHome; it can also accept parameters and state. The reference illustrates parameters for an email subject and body, but does not establish that any particular template is available for a given use case. Forge and OAuth 2.0 apps are also excluded from this template resource.
Use a template when an available catalog entry matches the needed behavior and its parameters cover the required customization. Otherwise, create the rule directly with the rule payload.
Choose the operation that matches the job
| Task | Endpoint or approach | What to account for |
|---|---|---|
| Browse rules | GET /rest/v1/rule/summary |
Supports cursor and limit pagination. |
| Find rules by criteria | POST /rest/v1/rule/summary |
At least one of trigger, state, scope, or limit is required. |
| Create a configured rule | POST /rest/v1/rule |
Send both rule and connections. |
| Create from a catalog template | POST /rest/v1/template/create |
Requires templateId and ruleHome; confirm a suitable template exists. |
| Edit rule configuration | PUT /rest/v1/rule/{ruleUuid} |
Use the full-rule structure and preserve IDs for existing components. |
| Change enabled state | PUT /rest/v1/rule/{ruleUuid}/state |
Send the required value. |
| Change scope | PUT /rest/v1/rule/{ruleUuid}/rule-scope |
Send ruleScopeARIs. |
| Remove a rule | DELETE /rest/v1/rule/{ruleUuid} |
The rule must be disabled. |
Handle errors and keep the integration maintainable
The rule-management operations document 400, 403, and 500 responses among their possible outcomes. Treat them as diagnostic signals: check request shape and required fields for a 400, caller access and permissions for a 403, and server-side handling for a 500. The documentation does not promise a retry policy, so do not blindly retry requests that may create or alter rules.
- Keep the full rule response and UUID available when preparing an update.
- Separate authentication failures from authorization checks; a valid token or session does not replace the required product permissions.
- Review Atlassian’s current API reference and changelog before relying on a route, schema, permission, or app restriction in a deployed integration. The API is versioned in the route, and documented behavior can change.
See the rule-management operations, API introduction, base path guide, and template reference for the current schemas and operation details.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
