Decide
The logic itself — the part a policy owner edits.
- Rule
- Decision Table
- 2D Matrix
- Scorecard
- Split
- Merge
- Loop
- Decision Flow
Documentation
What a decision flow is made of, how to test it, and the API your systems call once it is live. One endpoint, one API key, one response that explains itself.
Quickstart
Draw the decision on the canvas — rules, decision tables, splits, and code steps connected into one graph. Every outcome has an explicit path, so a reviewer can follow the logic without reading code.
Run representative cases through the draft. The trace shows the path taken node by node, so you fix the logic before a customer meets it — not after.
Publishing makes a version eligible for live traffic. Your integration keeps calling the same endpoint; the version behind it is a decision you make in the product, not a deploy.
POST the input to the flow's decide endpoint with your API key. The response carries the output, the version that produced it, and the trace behind it.
Decision API
curl -X POST https://api.arborule.com/run/api/v1/flows/YOUR_FLOW_SLUG/decide \
-H "X-Api-Key: $ARBORULE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"data": { "first_name": "Grace", "last_name": "Hopper" },
"metadata": { "grouping_id": "application-4821" }
}'{
"decision_id": "01J8ZQ...",
"status_code": "succeeded",
"created_at": "2026-07-30T14:02:11Z",
"environment": "live",
"grouping_id": "application-4821",
"duration_ms": 41,
"input": { "first_name": "Grace", "last_name": "Hopper" },
"output": { "decision": "approve", "limit": 12000 },
"trace": [ /* node-by-node record of the path taken */ ]
}Every call carries an X-Api-Key header. Keys are created per workspace and scoped to what they may do, so an integration that only decides cannot also edit a flow.
datametadata.grouping_idmetadata.versioncontrol.async| Method | Path | What it does |
|---|---|---|
| POST | /run/api/v1/flows/:slug/decide | Run the published version of a flow against live traffic. Traffic-routed by weight and sticky per grouping_id. |
| POST | /run/api/v1/flows/:slug/sandbox/decide | Run a draft version in Sandbox. Same request and response shape as live, so the call you test is the call you ship. |
| GET | /run/api/v1/flows/:slug/versions | List the flow's versions and their status, so a caller can pin one by name. |
| GET | /history/api/v1/decisions | Page through recorded decisions, filtered by flow, environment or grouping_id. |
Each flow also publishes an OpenAPI 3.1 document describing its own input and output schema, generated from the version you published — so client code is generated from the flow, not hand-copied from a page like this one.
Environments and versions
Sandbox runs a draft; Live runs a published version. Both take the same request body and return the same response shape, so nothing about the integration changes when a flow graduates.
Live traffic is routed across published versions by weight and kept sticky per grouping_id, so the same application does not get two different answers mid-journey while a new version is ramping.
Node reference
The logic itself — the part a policy owner edits.
Bring in what the decision needs and put it in the right shape.
Where a decision needs judgment a table cannot express.
For the decisions that should not be made automatically.
Common questions
Send a POST to /run/api/v1/flows/:slug/decide on api.arborule.com with an X-Api-Key header and a JSON body containing your input under `data`. The response carries the decision id, the outcome under `output`, the environment it ran in, how long the engine took, and the node-by-node trace of the path taken. It is an ordinary HTTP call — there is no SDK to adopt and no callback to host for the synchronous case.
/run/api/v1/flows/:slug/sandbox/decide runs a draft version; /run/api/v1/flows/:slug/decide runs a published one. The request body and the response shape are identical, so the call you test is the call you ship — the only thing that changes is which version answers and whether the run counts as production traffic. Both are recorded in decision history under their own environment.
Set metadata.version to a published version's name. Leave it out and live traffic is routed across published versions by weight, kept sticky per grouping_id so the same application does not get two different answers while a new version is ramping. Pinning is what you want for a replay or a regression test; routing is what you want in production.
Every response includes a decision_id. GET /history/api/v1/decisions returns recorded decisions filtered by flow_slug, environment or grouping_id, so you can retrieve one by its id or list everything that happened to a given application. The record keeps the input, the output, the version that produced it and the trace — which is what an adverse-action notice or a file review needs.
Two different things, and the difference matters. A Manual Review node pauses the run: the API returns a pending decision and a review case immediately, and the same execution resumes from that node once someone answers. A Create Case node does not pause anything — the flow opens a case for a reviewer and carries on returning its answer, so nothing waits on a human.
No. The decision API is HTTP and JSON, called with an API key header, so anything that can make a request can call it. Each flow also publishes an OpenAPI 3.1 document describing its own input and output schema, generated from the version you published — so if you do want a typed client, generate it from the flow rather than hand-writing one against this page.
Start reading in the product
Every flow carries its own API reference, generated from the version you published. Create a workspace to build one and read the docs it produces.