Connector Rules Now Self-Service via Beta API

Previously, if a customer wanted to create a custom connector rule, they had to engage with SailPoint’s Professional Services team. Today we announce the introduction of REST APIs that allow users to create and deploy their own custom rules without needing approval from SailPoint.

Please keep in mind that these APIs are currently in beta, and subject to change at any time without notice. That being said, we appreciate any feedback our developer community can give us in regards to improving the Connector Rules API. If you would like to see additional features or changes to the API, please create and vote for ideas in our Developer Ideas Portal. Our product team monitors the ideas portal and takes feedback seriously!


Hi @colin_mckibben ,

I get “Access Denied” error when invoking the APIs. I have the Admin capability on the tenant. Any thoughts?


@nasr_shah, it’s working for me. Can you please share your request details? Also, there are several types of admin in IDN. You need to be ORG_ADMIN to use this endpoint.

@nasr_shah I just did the list, but it’s working for me.


@colin_mckibben Is this just for a limited number of Rule types? We have some BeforeProvisioning rules, and they don’t show up in the /connector-rules returned.
ConnectorAfterModify and WebServiceAfterOperationRule do show up, along with a WebServiceAfterOperationRule and WebServiceBeforeOperationRule with no source code.


Hi Chrisp,

BeforeProvisioning rule is Cloud executed rule

As per document we can only access Connector Rules.

Thank you!
Sailaja Prathi

1 Like

@dsaini, thank you for joining the developer community! I think you may have posted in the wrong topic, as this topic is about the newly released Connector Rules API. Can you please create a new topic in the IDN category?

hi - sorry, its working now. I had to change the capability to Org_admin.

@colin_mckibben sorry about this. I have created new topic for the search issue with V3.

Is there a plan for an API to perform log retrievals and/or updating the file? This direct rule upload will be very helpful, but I think these other two items are also required to make the rule development process for IDN optimally developer friendly.

Hi @howard_west ,

I think log retrievals are not possible at the moment using APIs. However, we can update the “” file. Please find the “Update Logging Config” section in the documentation below:

Hope this helps!

What about a database schema? Most log managers can pull logfiles from a view generated off the audit tables?

Log files, and Log4j settings, have little or nothing to do with Audit Event data that are stored in the audit tables. Occasionally an Audit Event has a stack trace from an error, but that is a rarity reserved for provisioning exceptions. Accessing Audit Events is done via the v3 Search API that extracts Audit Event records from IdentityNow’s back-end search engine.

I noticed when I was looking in the database there is an audit table which corresponds to the audit events.

If I had a schema (a definition of the logging tables) I could map the audit and logging events stored in the database to the Database Adapters in which ever log manager (like Splunk or Elastic Search) we use.

I searched your Documentation for a Schema mapping to figure this out, but I couldn’t find one.
I know these exist because I see partial correlation between the GUI data and data in the database tables.
Without a Schema of how to map the Gui data to the table information , I can’t send it to a log manager though.



Could you please advise how can I apply connector WebServiceBeforeOperationRule rule on a source?
All docs refer how to do it on JDBC only :frowning:

It is not mentioned anywhere for WebService and there is no property in source API configuration (only cloud rules references)
@colin_mckibben - any docs where I can find it?

I reverse engineered it as connectorAttributes\beforeRule , but found it on the net, not sure if proper path



Number 6 is sequenceNumberForEndpoint for your operation. So update that accordingly.


Brilliant - works :slight_smile:

/connectorAttributes/connectionParameters/[operation type]/beforeRule

1 Like

Hello @JakubDudek @gaurav_jain,

I am calling PATCH /v3/sources/:id to attach WebServiceBeforeOperationRule to source, but getting “The request was syntactically correct but its content is semantically invalid.” Error. Could you please share what was your patch body. Also, are there any logs where I could see more details about this error ?

        "op": "replace",
        "path": "/connectorAttributes/connectionParameters/3/beforeRule",
        "value": "Add Groups to CreateAccount"