Auditing

Event Logs record changes to your rules: created, updated, deleted, shared. Service Logs record API calls to your space: the method, path, and response. They are connected, since one call can produce several changes, but they answer different questions. Event Logs tell you what happened to a rule; Service Logs tell you what request made it happen.

Audit Logs are a native, enterprise-grade tracking feature that records every single execution within your workspace. Whenever an application calls a Decision Table, Decision Tree, Scripting Rule, or Flow via our API, the engine captures the exact timestamp, the rule version used, the raw input data, and the final output returned. It serves as your permanent, tamper-proof system of record. More about Audit Logs you can find here: https://www.decisionrules.io/en/product/audit-logs/.

Event Logs and Service Logs run automatically for your space, so the trail is there whenever you need it. Decision-level Audit Logs are the exception: you switch those on per rule, so you only generate the ones you actually want.

Open any Event Log or Service Log entry and use Inspect to jump between them. Behind the scenes they share a correlation ID, a single identifier stamped on every record from one operation. Search either tab by that ID to pull up everything a call touched at once.

Yes. Send your own correlation ID as an x-correlation-id header on your API call, and the same value shows up in both Event Logs and Service Logs. The response hands it back to you as well, so your integration can capture it and line everything up on its side.

Event Logs and Service Logs are retained for 90 days, then removed automatically. An event and the call that produced it expire together. For decision-level Audit Logs, you set the lifespan yourself per rule, so you can match retention to whatever your industry requires.

Decision-level Audit Logs are built for exactly that. Capture the input and output of every solver run and pull it into your BI platform through the Business Intelligence API, or connect it straight to Power BI. It turns your decision history into something you can analyze, not just read.

No, and that is by design. Logs are generated and stored per rule, so enable them where the trail matters, like production rules under compliance or ones you are actively debugging.

Because one keeps the record and the other sounds the alarm, and you want both. Webhooks push you the moment something happens, so your systems react without anyone watching. Event Logs hold the full history in one place, so when a Webhook fires you can open the log and see the complete context.