Rule Execution API

The Rule Execution API is an upgraded version of the classic Rule Execution Service. It is backward compatible and has been improved to provide a better experience for executing decisions and rules. Since the Rule Execution API is intended to replace the classic Rule Execution Service, it contains the same end point definitions and request attributes for ease of upgrading.

The Rule Execution API differs from the Decision API in that it gives you a complete set of runtime options allowing you to add runtime overrides, additional metadata in the response, and more. For the full description of available options and how to use them, please explore the documentation for calling the irServer - Rule Execution Service. 

For existing InRule SaaS users, both the Rule Execution API and the classic Rule Execution Service will be available for a limited period to allow for transitioning over time. 

Rule Execution API End Points

The Rule Execution API provides the following end points.  Again, these are the same end points that exist in the classic Rule Execution Service and accept the same request body and headers. Links to example requests are provided below for each end point. All HTTP methods are POST.

Execute decision 

/HttpService.svc/ExecuteDecision

• see examples

Execute rule set

/HttpService.svc/ExecuteRuleSet

• see examples

Apply rules

/HttpService.svc/ApplyRules

• see examples

Execute independent rule set

/HttpService.svc/ExecuteIndependentRuleSet

• see examples

Additional information describing all request attributes can be found in the article, HTTP Request Member Definitions.

XML content type is no longer supported with the Rule Execution API. Please use JSON content types only for requests and responses. The embedded JSON data in the request EntityState and InputState attributes no longer requires encoding, but it is still supported for backward compatibility.