Integrating the decision engine into your architecture: API, webhooks and asynchronous decisions
How a decision engine fits a modern stack: policy execution over REST API with tokens, signed webhooks for async flows and execution export for BI.
Updated July 2026 · 6 min read
In short
The decision engine integrates over a REST API with short-lived token authentication: one call executes the policy and returns the decision. For flows with no user waiting there are signed webhooks, and for high-volume runs, batch processing — all three patterns backed by the same policy.
For an architecture team, a decision engine is just another service that has to integrate cleanly: standard authentication, a predictable API, and synchronous or asynchronous patterns depending on the use case. This guide walks through the three pieces: the API, webhooks and the governance around them.
Written bySantiago Etchegoyen · CTO at uFlow
CTO at uFlow. Responsible for the decision engine's architecture: API integration, orchestration of credit bureaus and data sources, running models in production, and platform security.
Synchronous execution: one call, one decision
The base case is plain REST: the system authenticates with its own credentials, obtains a short-lived token and executes the policy with its input parameters. The response carries the decision result, with configurable levels of detail depending on what the consumer needs; the exact authentication scheme and endpoints live in the technical documentation.
One design fact that prevents surprises: decision latency is usually dominated by the external data sources the policy calls, rather than by the engine itself. A well-orchestrated policy — waterfall logic, concurrent calls, re-query rules — is also a faster API.
Webhooks: notification when the decision is done
For flows where nobody is waiting on the response in real time, the engine notifies via webhook when a transaction finishes. The subscription is configured with two things: the destination URL and a signing key, which lets you verify the authenticity of every notification before processing it.
The payload is configurable: you define which execution variables travel in the notification, and the webhook delivery log stays available for debugging integrations.
Sync, async or batch: choosing by use case
All three patterns can coexist in the same installation, with the same policy behind them:
- Synchronous for live loan origination: there is a user waiting for the answer on screen.
- Asynchronous with a webhook for background processes: staged onboarding, work queues, verifications that arrive later.
- Batch for high-volume runs: campaigns and portfolio re-scoring, with results exported as a file.
- In every case: client timeouts above the policy's worst case, idempotent retries and the transaction ID as the correlation key.
Integration with governance included
The same governance building blocks used across the rest of the engine apply to the integration: one user and one API key per integrating system — identity, permissions and revocation per integration — short-lived tokens, and execution permissions kept separate from editing permissions.
And to close the data loop, the execution export feeds your data warehouse or BI tool: engine decisions enter the same analytics plane as the rest of the business, with the transaction ID as the key to reconstruct any individual case.
Technical documentation
How this is implemented in the engine, step by step.
Common questions
How do I know a webhook notification is legitimate?+
Every subscription is configured with a signing key. The consumer verifies the signature on each notification before processing it: if it does not validate, the notification is discarded. It is the same signed-webhook pattern used by any serious payments or messaging provider.
What does the API expose besides executing policies?+
Beyond execution, the API covers querying and exporting executions and managing webhooks, always within the permissions of the authenticated identity. The details of endpoints and parameters are in the technical documentation.
Related topics
Would this work for your decisioning process?
Transform your credit assessment process with the decision engine.