Base URL
Authentication
Same API Key as the Management API. Include in every request:Execution Modes
LexQ provides 4 execution modes. Choose the one that fits your use case:Single Group Execution
Evaluates all active rules in the currently deployed version of a policy group.Request
Response
data.traceId is the execution’s audit handle — store it alongside your own records to trace this execution later.
The data object exposes three layers of state explicitly:
inputFacts— facts as received from the request, normalized.mutatedFacts— only the facts whose values were changed by rule actions.generatedVariables— variables created by rule actions that did not exist in the input. Includes per-action change keys like{refVar}__delta(signed change fromMUTATE_FACT) and{targetVar}__delta(non-negative increment fromINCREMENT_FACT).
{ ...inputFacts, ...mutatedFacts, ...generatedVariables }.
Idempotency
Include anIdempotency-Key header to prevent duplicate executions. If a request with the same key has already been processed, the original response is returned without re-executing the policy.
Specific Version Execution
Executes a specific version of a policy group, bypassing traffic routing. Useful for A/B testing a candidate version or testing a rollback target before switching.The version must be in
ACTIVE (published) status. DRAFT versions cannot be executed via the Engine API — use Dry Run for testing DRAFT versions.Batch Execution
Executes multiple fact sets against the same policy group in a single call. All requests in the batch are evaluated against the same version for consistency.Request
Response
sharedContext (per-request context takes priority on conflict).
Batch execution counts as 1 API call for TPS throttling, regardless of the number of items. However, billing is based on the total number of items.
Composite Execution
Evaluates the same facts against multiple policy groups in a single call. Useful when a transaction must pass through multiple policy checks simultaneously (e.g., product discount + cart coupon + shipping fee + membership points).Request
Response
The response contains mergedinputFacts, mutatedFacts, generatedVariables, executionTraces, and decisionTraces from all evaluated groups.
All target groups must be in ACTIVE status. If any group is DISABLED or not found, the entire request fails.
Requirements
Check which input facts a deployed version requires before calling the execution endpoint. Returns required keys, types, and an auto-generated sample request body.Request
Accept-Language header controls the language of the usedBy descriptions (en or ko).
Response
System Facts
Every tenant gets 3 pre-registered system facts available immediately after account creation. You do not need to create these manually:
Whether each fact is required for a particular execution depends on which rules in the deployed version reference it. Call
GET /groups/{groupId}/requirements to see exactly which facts the engine expects.
All other facts (e.g., payment_amount, customer_tier, order_region) are user-defined and must be registered via Fact Definitions before use.
Error Handling
All errors follow the same envelope shape:
For the complete code registry across all domains (auth, billing, simulation, etc.), see Error Reference.
Next Steps
Dry Run
Test rules without side effects before going live.
Fact Definitions
Register custom input variables for your rules.

