REST API

One API call. One clear answer.

A decision API for every system you run. Send the record, get the answer back as JSON in milliseconds, and leave the rules to the people who own them.

See your decision running How it works

Incoming request

evaluating

Can account 40117 take this order on credit?

Look up the account's credit limit and current balance.
If the balance plus the order is over the limit, decline on credit.
If the delivery country is on the restricted countries list, refer for review.
Otherwise, approve.

Answer, with the reason

The answer comes back as JSON saying approved, with the remaining credit of 1,800 GBP as an output value. The account has a 10,000 GBP limit and 5,000 GBP outstanding, so the order fits, and the United Kingdom is not on the restricted list. The call, its inputs and its trace are saved in run history under the web shop's key.

Sound familiar?

Every application ends up with its own copy of the rules

The web shop has a credit check. So does the ERP. So does the sales app. They were all written from the same policy, at different times, by different people.

The same rule, written three times

Each system has its own version of the logic. When policy changes, three teams have to change three codebases, and one of them always lags.

Developers maintaining policy

Your developers should be building product. Instead they are fielding tickets to move a threshold from 5,000 to 7,500.

Answers you cannot trace

When the app says no, the log says 'declined'. It does not say which rule, which value or which version of the policy made that call.

The quiet cost

What duplicated rules quietly cost

Customers get different answers depending on which channel they use.
Policy changes take as long as the slowest release train.
Support cannot explain a decision without asking a developer.

Before and after

From rules in every app to rules as a service

Today

Each application carries its own copy of the business rules.
A rule change means code changes and releases in several places.
Logs show the result, not the reasoning.
Developers own policy by accident.

With Condexa

Every application calls one published decision.
The rule changes once, in Condexa, and every caller gets it.
Every call is recorded with its inputs, outputs and trace.
The business owns the policy; developers own the integration.

How you get there

How the Condexa decision API works

1
Issue a key to each application
Create an API key for each named application, such as the web shop or the ERP. You always know which system asked, and you can manage each key separately.
2
Send JSON, get JSON
Post the record or the input values to the decision. Condexa runs the Active version and returns the output values as JSON, in milliseconds for compiled and cached decisions.
3
Look back at any call
Run history records every call with what was sent, what came back and the full trace. When someone asks why, you open the run and see.

A worked example

Worked example: one request, one answer

The web shop sends Condexa a request: customer account 40117, order total 3,200 GBP, delivery country United Kingdom. It uses the web shop's API key and calls the 'Order credit check' decision.

The rules, in plain English

R1Look up the account's credit limit and current balance.
R2If the balance plus the order is over the limit, decline on credit.
R3If the delivery country is on the restricted countries list, refer for review.
R4Otherwise, approve.

Condexa answers

FAQ

Questions people ask

What is a decision API?

A decision API lets an application send the facts of a case and get back a business decision, such as approve, decline or who must sign off. The rules live behind the API instead of inside each application, so they can change without a code release in every system that uses them.

What does 'rules as a service' mean?

Rules as a service means your business rules run as a shared service that any system can call, rather than being copied into each application. Condexa provides this: publish a decision, and every system calls the same Active version over REST.

How do applications authenticate with the Condexa API?

Each calling application gets its own API key, issued to a named application. The key is sent with each request, so every call in run history is tied to the system that made it.

Which version of a decision does the API run?

The Active version. Drafts can be tested in Condexa without affecting callers, and when you publish a new version it becomes the one the API runs. A decision can also be switched off entirely.

Which languages and platforms can call it?

Anything that can make an HTTPS request and handle JSON: C#, Java, Python, JavaScript and others, plus Power Automate, Power Apps, Dynamics 365 plug-ins, ERP and CRM systems.

How fast is the Condexa API?

Decisions are compiled, and cached decisions answer in milliseconds, so they can sit inside a live order or quote flow without slowing it down.

Keep exploring

Related decisions and guides

Features

Decision trace

Someone asks why the system said no. Open the run and show them every step, every value and the rule that decided.

Features

Versioning

Nervous about changing a live rule? Draft it, test it, publish it, and keep every earlier version to fall back on.

Integrations

Dynamics 365 and Dataverse

Outgrown Dataverse business rules? Run real decisions on live Dataverse data and call them from any app or flow.

Compare

Build vs buy a rules engine

Building your own rules engine looks simple. The versioning, testing, tracing and support are where the work is.

Glossary

Decision engine vs rules engine

A rules engine evaluates individual rules against data; a decision engine combines rules, data lookups and logic to answer a whole business question and explain the result.

Make your first call to a decision you wrote yourself

Bring a decision your team makes every week. We will build it with you, live, test it against your own examples and show your systems calling it.

Book your 30-minute demo See how it works

No slides. Your decision, built live. No obligation.