Skip to main content



Rule Execution API

The Rule Execution API is an upgraded version of the classic irServer 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 endpoint 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.

Rule Execution API endpoints​

The Rule Execution API provides the following endpoints. Again, these are the same endpoints 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 endpoint. All HTTP methods are POST.

Execute decision

/HttpService.svc/ExecuteDecision

Execute rule set

/HttpService.svc/ExecuteRuleSet

Apply rules

/HttpService.svc/ApplyRules

Execute independent rule set

/HttpService.svc/ExecuteIndependentRuleSet

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

Executing decisions and rules using Swagger​

Executing your decisions and rule sets from Swagger is a straightforward process using the Rule Execution API. The Rule Execution API uses a unified endpoint that accepts complex request bodies containing all supported execution attributes.

The Swagger provides comprehensive details about the request structure, including all available attributes for the complex request body. This allows you to understand the full data contract and construct requests with the specific parameters needed for your rule execution scenario, regardless of which rule application you're targeting.

Rule-Execution-API-Swagger-Page

Rule Execution API vs. classic irServer​

Content types

  • XML content type is no longer supported with the Rule Execution API. Please use JSON content types only for requests and responses. This essentially means that both the request body and EntityState must be JSON. If there are specific circumstances that require the use of XML in the execution request, please contact InRule Support to discuss potential options.

Encoding/Decoding

  • The Rule Execution API allows entities to be passed in as JSON objects and no longer requires encoding. IrServer required the embedded JSON data in the EntityState and InputState attributes to be encoded as a string representation when passed in as part of a request.
  • Encoding is still supported on the Rule Execution API for backward compatibility. The response encoding will be determined by the request encoding.

Additional options

  • When specifying the ruleEngineServiceOutputTypes on a request, the Rule Excution API now includes the option: executionStatistics.
  • Setting executionStatistics to TRUE will generate a summary containing statistics regarding the rule execution that will be included in the response.
  • Setting the requestId attribute in the Rule Execution API request body will uniquely identify the execution request and related event log entries.
  • The RuleAppRevision response attribute contains the RuleApp revision that was pulled from the catalog for execution. By default, this is the latest revision in the catalog unless an explicit revision or label was specified in the request.