Synchronous Execution

Most runs are queued: you start them and read the results afterwards. Synchronous execution is the other shape — the engine runs the rule set to completion and hands back the answer inside your own HTTP request, so your code can act on the decision immediately.

When to use it

Use it when something is waiting on the answer. A checkout deciding whether to apply a discount, an application deciding whether to approve or refer, a request being scored for fraud before it is accepted — in each case the caller cannot continue until the rule set has decided.

Keep using the queued endpoint when nothing is waiting: overnight batches, notifications, anything that pauses for a person, and anything that legitimately takes minutes.

Enabling it on a rule set

Open the rule set's Interface tab, declare the inputs callers may send and the outputs they get back, then turn on Allow synchronous execution. The same inputs and outputs also describe the rule set to MCP clients, so a rule set already exposed as a tool has nothing extra to declare.

Outputs are a deliberate allow-list: only the context keys you name are returned. Everything else the run computed stays internal, and any value marked as secret is redacted.

Calling it

POST to the execute endpoint with an application API key in the X-API-KEY header. Unlike the queued endpoint, this one takes a JSON body whose properties are your declared inputs:

POST /api/v1/rulesets/<rule set id>/executions
X-API-KEY: <your key>
Content-Type: application/json

{ "amount": 5000, "state": "TX" }

A successful call returns the declared outputs, plus the identifiers for finding the run later:

{
  "Outcome": "Completed",
  "Outputs": { "decision": { "DataType": "String", "Value": "Refer" } },
  "CorrelationId": "...",
  "RunId": "...",
  "HasErrors": false,
  "DurationMs": 42
}

A property that is not one of your declared inputs is rejected rather than ignored, so a misspelled field is reported instead of silently running the rule set without it. Declared inputs marked as required must be present.

What disqualifies a rule set

A synchronous run has to produce its answer before the response is sent, so it cannot contain anything that pauses the run and waits for a separate request to resume it:

• a human intervention action, which waits for a person to complete a form;
• an extension callback, which waits for an extension to call back in;
• an API action configured to continue asynchronously.

Being slow is not disqualifying. A rule set may call APIs and AI models; those finish, and the run's deadline bounds them.

The Verify tab tells you where a rule set stands before you turn the setting on, and saving fails if a rule would pause the run. If a run reaches a pausing action anyway — possible when a rule set calls another one chosen at run time — the request fails with 422 naming the action, and the partial run is still recorded.

Deadlines

Every synchronous run is bounded. The default budget is 30 seconds; add ?timeoutMs= to the request to ask for less, up to a ceiling of two minutes. A run that exhausts its budget returns 504 — and still returns a correlation id and run id, because the run happened and its logs are worth reading.

Latency and hosting

Everything else about the run is unchanged. It appears in run history, feeds decision analytics, and counts against your plan exactly as a queued run does — a decision costs the same however it was asked for.

Compared with the queued endpoint

• Body — JSON matching your declared inputs, rather than form data.
• Response — the declared outputs, rather than just a correlation id.
• Nested rule sets — always run inline, so their results reach the caller.
• Version — always the published version; drafts are never run this way.