Rule Solver API AERO (v2)
Solve a rule on AERO solver and get the result in the same call.
The Rule Solver API is the main way to evaluate your rules from your own application. You send the input data, and the rule — a Decision Table, Decision Tree, Decision Flow or any other rule type — returns its output in the same call.
This page describes version 2 of the API. It runs on solver v2, also called AERO, where all new features are released.
Below you will find the specification of this endpoint.
Swagger
You can check out these endpoints and call them right away using swagger.
Swagger UI: https://api.decisionrules.io/api/solver/docs
Swagger JSON File: https://api.decisionrules.io/api/solver/docs/json
Solves the rule on solver v2 (Aero), where all new features are released. If the {ruleVersion} parameter is omitted from the path, the last published rule version will be used automatically.
Please insert: "Bearer <SOLVER_API_KEY>" into Authorization header.
Unique identifier for the rule that is common to all rule versions. Instead of rule ID, it is possible to use a rule alias.
Rule version. If not provided, the latest published version is used.
The media type of the request body.
application/jsonExecution strategy used to evaluate the rule. See Execution Strategy.
STANDARDPossible values: Lookup method, used only with Lookup Tables.
Correlation ID, if you'd like to set it manually. If not present, it will be generated automatically and returned in the response.
On-premise deployments only: set to true to solve rules with the status pending. On DecisionRules Cloud this header has no effect.
Whether to create and save an audit of the solve.
truePossible values: Number of days after which the audit will be deleted. Default is 14 days.
14JSON object that describes the input json data.
Object specifying solver options.
OK
Bad Request. Returned for an unknown rule, a missing API key, or a request body that does not match the expected shape.
Authentication failed.
POST /rule/v2/solve/{ruleId}/{ruleVersion} HTTP/1.1
Host: api.decisionrules.io
Authorization: Bearer YOUR_SECRET_TOKEN
Content-Type: application/json
Accept: */*
Content-Length: 81
{
"data": {
"monthlySalaryInDollars": 2000,
"typeOfContract": "employee"
},
"options": {}
}[
{
"car": {
"price": "666666",
"seats": {},
"discount": {
"low": "2",
"high": "33"
}
}
}
]Request example
{ruleVersion} is optional. Leave it out, as in /rule/v2/solve/{ruleId}, and the latest published version of the rule is used.
For easy Rule Solver API calls go to Integrations → Code Samples. Note that the cURL code can be copy/pasted directly to Postman.
If you're using the Regional Cloud version of DecisionRules, read more about API calls here.
Note that you can use the rule alias instead of the rule ID to identify the rule. In that case, make sure that the rule alias is unique within the space, otherwise the request will fail.
You must provide your own API key after the Bearer keyword. Generate it in the API Keys section of the app.
Body
The body of the request needs to have the following structure.
For example, it may look as follows. The object under the data key needs to correspond to the input model of the rule you want to solve, see I/O Model.
If the input is not wrapped in data, the request is rejected with 400. See Invalid requests.
Options
The request body can contain an optional options object that configures how the rule is solved. Each option below says which rule types it applies to.
Included Condition Cols
Decision Tables only. Specifies the condition columns to evaluate; all other columns are ignored. Columns are identified by the name of the input variable related to the column.
With this configuration, only the columns related to client.age and portfolioAmount are evaluated. The columns for productCount.accountsAndCards and productCount.Investments are ignored, even though their values are sent.
Excluded Condition Cols
Decision Tables only. Specifies the condition columns to ignore. Columns are identified by the name of the input variable related to the column.
With this setup, the columns related to client.age and portfolioAmount are ignored, and only the productCount columns are evaluated.
Quit Solve On Fail
Determines whether a failed HTTP function call stops the solve. Applies to HTTP functions used directly in the rule you call — in a Decision Table, Decision Tree or Decision Flow.
When set to true, an error from an HTTP function — HTTP_GET, HTTP_POST, HTTP_PUT, HTTP_PATCH or HTTP_DELETE — stops the solve, and the Rule Solver API returns an error response instead of 200. In Flows, errors from parallel branches and bulk executions stop the solve too.
When the option is omitted or set to false, a failed HTTP call does not stop the solve.
Invalid requests
The solver checks the request before running the rule, and returns 400 with a message that says what is wrong:
Empty body or malformed JSON
request body must be valid JSON
Input not wrapped in data, e.g. {"creditScore": 700}
unexpected top-level field 'creditScore'; input data must be wrapped in "data"
data is not an object, e.g. {"data": "hello"}
solve data must be an object or array of objects
A bulk array with a non-object in it
bulk solve data item 1 must be an object
options is not an object
options must be an object
A rule that takes no input can be called with {}.
Simple Solve
Simple solve means that you send a single set of input data and the solver thus evaluates this single input. The response is an array of results (given e.g. by the individual rows of a decision table).
Simple Request
This is how the object sent under the data key could look for the given rule.
Simple Response
And this would be the response. Only one row of the decision table was triggered, so the output is an array with a single object, holding the outputs set on that row.
Bulk Solve
On the other hand, DecisionRules also supports the bulk solve, which is a call to the solver where you include multiple sets of input data. Each set is evaluated individually, with no relation to any other, and the solver returns an array of the corresponding output objects.
Bulk Request
This is how the JSON under the data key of a bulk request is structured. Instead of an input data object, you send an array of these objects.
Bulk Response
The outer array corresponds to the array sent in the request. Each inner array holds the results for one input, just as in a simple solve. In this example, one row of the decision table was triggered for each input.
How the solver version is applied
Requests to this endpoint are evaluated by solver AERO (v2). This section explains how to check which version evaluated a request, how the version carries over to the rules a rule calls, and the few cases where solver GAIA (v1) is used instead.
Response headers
Every response says which solver version evaluated the request, errors included:
A response from solver GAIA (v1) carries v1 and gaia.
Rules that call other rules
When a rule calls another rule — from a flow node, a function or a script — the called rule runs on the same solver version. You choose the version once, in the call you make.
Exceptions
Rule Flows and AI Agents are always evaluated by GAIA (v1), whichever version you call.
You can still call these rules with any version. When you call one directly, the response header and the audit show v1, because that is the version that evaluated it.
Last updated
Was this helpful?