GET /api/rule/list

There are two ways to get rules.

Get rules via CLI

The latest release of the CLI (2.1.4) allows you to list rules from your tenant.

Get rules via API

The replacement for this endpoint is to use the SP Config API to export rules for your tenant.

https://developer.sailpoint.com/idn/api/beta/sp-config

This is a three step process.

  1. Initiate a configuration export using https://developer.sailpoint.com/idn/api/beta/export-sp-config. Use the following request body payload to export rules.

    {
      "description": "Export all available rules",
      "excludeTypes": [],
      "includeTypes": [
        "RULE"
      ],
      "objectOptions": {}
    }
    

    Save the jobId that is returned for use in the next two steps.

  2. Check the status of the export job using https://developer.sailpoint.com/idn/api/beta/get-sp-config-export-status. You will need to provide the jobId from the last step in the URL of this endpoint. Depending on the size of data that needs to be exported, this can take a few seconds to a few minutes. You will need to wait for the status to show COMPLETE before you can download the results.

  3. Download the results using https://developer.sailpoint.com/idn/api/beta/get-sp-config-export, inserting the jobId from step 1 into the URL. This will return a JSON response of all the rules in your tenant.

Get rules via Config Hub

Using Config Hub, you can export rules from the user interface.

How would we be able to get a cloud rule name / ID to attach to sources? Would the expectation to be to use SP-Config to initiate an export of rules and the get an name / ID from there? That should work fine - just annoyingly cumbersome compared to having an endpoint for cloud rules.

2 Likes

We are currently going through an IDN implementation. This endpoint is crucial to troubleshooting cloud rules. Otherwise, we cannot view the rules to check the logic as far as I know. It’s rough enough we have to submit a ticket every time they need updated, but being unable to view them is going to be a big roadblock.

Is there another method of viewing the script the cloud rule is running? Can the deprecation simply be pushed until the replacement is available?

3 Likes

I agree, this feels like quite an important endpoint for troubleshooting rules. The description is very clear to me, when you say “There will not be a public replacement available before March 31st” does that mean that there will be a replacement on March 31st or that there’s no planned replacement or ETA for a replacement? As @jalexand says, it’s already a pain that we have to pay extra to get these updated, would be even worse if we had to pay just to see what the rules look like.

1 Like

Good news. Our SP config API can export all rules, including cloud rules. I have update the first post in this topic to demonstrate how to do this.

3 Likes

Excellent, I’ve confirmed I was able to retrieve the rules. It’s not as streamlined, but it solves the ask nonetheless. Thank you, Colin!

1 Like

Umm, HELP!! - This does NOT return any data, it just starts a background job.

Can you please advise how to update the ruby I/O TOOL (idnio-2.3.4b) to manage this?? (rules.rb) (We’ve been relying on this and have history for 3+ years as our fortnightly backup.)
My ruby knowledge is only as far as I can google - or can AI rewrite it for us?? :wink:

#
# Exports Rule configurations.
#
def self.export( directory )

response = IDNAPI.get( "#{$url}/cc/api/rule/list", $token )

case response
when Net::HTTPSuccess

 rules = JSON.parse( response.body )

etc…

Sorry about that. You are correct in that this a three step process. I have updated the post to describe each step needed to get the rules, as well as how to do this using Config Hub.

You will need to update your ruby script to follow the three step process mentioned above. I too would need to google the right ruby code :wink: but here is some pseudo code to help you update your script. This is not ruby code, just an example of the steps you would need to take in your code to accomplish exporting rules. You’ll need to google the correct ruby code to make this work.

payload = {
  "description": "Export all available rules",
  "excludeTypes": [],
  "includeTypes": [
    "RULE"
  ],
  "objectOptions": {}
}
# initiate the export job for all rules
response = IDNAPI.post("/beta/sp-config/export", payload)
jobId = response["jobId"] # Save the jobId

# Check the status of the job every 5 seconds until it is complete
exportStatusUrl = "/beta/sp-config/export/" + jobId
while (JSON.parse(IDNAPI.get(exportStatusUrl).body)["status"] != "COMPLETE")
    wait(5) # wait 5 seconds

# Get the results
exportDownloadUrl = "/beta/sp-config/export/" + jobId + "/download"
response = IDNAPI.get(exportDownloadUrl)
rules = JSON.parse(response.body)
1 Like

Hi Colin.

The Visual Studio Code Extension for IDN included listing Rules (though just connector rules for whatever reason). We use that tool a large amount for our ongoing enhancements as we flesh out our IDN implementation from last year (2023). To your knowledge is the maintainer of that tool incorporating the new approach for Rules ?

T

The VS Code Extension is a community tool maintained by @yannick_beot .

1 Like

Right, thanks. And I likely answered my own question as it looks like the VS Code rules management uses the Beta Connector Rule Managment APIs, so it should still be ok. And that explains why it just shows the Connector rules and not any Cloud rules.

One key difference I note in the new approach to retrieving Rules is that the beta/sp-config/export API response does not seem to include any of the default rules vs. the /cc/api/rule/list API which included the default/demo rules. i.e. only rules which have been customized in the target tenant are returned by beta/sp-config/export.

Pros and Cons to this difference. Is this on purpose ?

1 Like

Possibly just an oversight. I don’t think it would be intentional to leave out rules.

@reklawttocs
Currently, the VSCode plugin can export all rules through the SPConfig.
I have just tested and by selected all rules, cloud rules will also be exported.

Actually, I just learned from Colin’s answer that the SPConfig could be leveraged to get the cloud rules.

Not sure what I can do more.
Cloud rules will not be “editable” as connector rules.
Feel free to create an issue as an enhancement request and to write your expectation, expected behavior and all.

I hope there will be an API available similar to GET /api/rule/list.
Now we are dependent on using the CLI, sp-config or the config-hub, all of which require additional steps, is less user friendly and is not consistent with all other objects that are easily available through GET /v3/any_object_types.

Something like GET /v3/rules that directly gives a JSON array of the rules would be consistent here. We already have GET /beta/connector-rules, which only shows the connector-rules. Instead of /v3/rules it would also be fine for me if an API like GET /v3/cloud-rules would become available. Then we can also use APIs to fetch all rules easily.

Kind regards,
Angelo

5 Likes

1000% agreed. Having to go through sp-config, config hub, or vs code is significantly less user friendly than having a direct API endpoint to get at the data.

Just look at my documentation tool from dev days. Having to engineer in a solution for sp-config instead of having a direct API call is a lot more overhead than what is necessary IMO

to save everyone else a “google” search.

I appreciate you linking this. Still hoping we can release it to the community but no updates yet on that sadly.

1 Like

Similar to other posts, it would be good to be able to export all rules because, as it is currently working, we are not able to export any SDIM Integration BeforeProvisioning rules.

1 Like