Decision API

The Decision API accelerates the integration process with Swagger documentation for all your decision and rule set endpoints organized by their respective rule application. This paired with a simplified request and response model, dramatically reduces the time it takes to test and integrate your decisions and rules. 

Decision API endpoints

The Decision API provides the following base endpoints to execute decisions and rules. All HTTP methods are POST. 

Execute decision 

/api/{ruleAppName}/decision/{decisionName}

• e.g. /api/MortgageCalculator/decision/CalculatePaymentSummary

Execute rule set

/api/{ruleAppName}/{entityName}/execute/{ruleSetName}

• e.g. /api/MortgageCalculator/Mortgage/execute/PaymentSummaryRules

Apply rules

/api/{ruleAppName}/{entityName}/apply

• e.g. /api/MortgageCalculator/LoanInfo/apply

A significant improvement of the Decision API over the classic Rule Execution API is that the request body no longer requires a complex JSON object.  The body payload of the Decision API expects only the decision input or entity data as defined in the rule application. The same applies to the response body. This model conforms to what is traditionally expected from an API and diffuses the complexity that can create barriers to adoption.  

While the Decision API has endpoints for both decisions and rules, it is advantageous to use the decision endpoint when calling from your application. This allows you to define separate input and output data contracts for the request and response which can better align to your application needs. 

Executing decisions and rules using Swagger

Executing your decisions and rule sets from the Swagger documentation is a straightforward process that can be performed by either using the default Swagger page or by selecting a rule application from the dropdown. The default Swagger page can be thought of as a template that the rule application-specific endpoints are built from. By selecting a rule application, you will be presented with everything needed to call the API including the data contract specific to its decisions and rule sets.

It is not required to use the Authorize button when testing with Swagger from the InRule Portal, since it inherits from the portal authorization.

Request body

When selecting a decision or rule set, the body parameter will display the relevant request input and response output data models. You can then select Try it out to replace the default values with your test data and execute the request.

Response body

Once the request has been executed by selecting the Execute button, the response body and return code will be available in the Swagger response section. From here, you can inspect the response from the Decision API and verify that the execution output is correct. 

Supported request and response headers

When making an HTTP request to the Decision API, you have the option to pass in additional information by using the request and response headers below.

Request headers

• inrule-apikey – Include an API key for authenticating to the Decision API
• inrule-label – Pass in a label for the rule app revision to execute
• inrule-revision – Pass in a value for the rule app revision to execute
• inrule-runtime-overrides – Pass in runtime overrides as part of the request

For additional information regarding the supported overrides, please see the article, Overriding RuleApp Endpoints at Runtime.

For SaaS tenants
It is recommended to use the global runtime overrides defined in the SaaS configuration settings. Below is an example of the override header format:

Key: inrule-runtime-overrides-name-type-property
Value: youroverridevalue

Response headers

• inrule-notifications – This header will contain a list of any notifications generated as a result of the rule execution