> ## Documentation Index
> Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt
> Use this file to discover all available pages before exploring further.

# Compliance and audit

> How Flowker supports regulatory compliance with immutable audit trails, hash chain integrity, and validation-before-Ledger architecture.

export const GDSL = ({children}) => <Tooltip headline="DSL (Domain-Specific Language)" tip="A simplified language designed for a specific purpose — in Flowker's case, for defining workflow steps and rules without writing general-purpose code." cta="See glossary" href="/en/glossary">
    {children}
  </Tooltip>;

Flowker is built with regulatory compliance as a core design principle, not an afterthought. Workflow lifecycle events, execution events, provider call events, and provider configuration events are recorded in an immutable audit trail — giving compliance teams the evidence they need to demonstrate adherence during internal reviews and regulatory audits. Note that not every API call is logged; the audit system captures domain-significant events, not raw HTTP request logs.

## Why audit trails matter

***

Financial institutions operate under strict regulatory requirements that demand complete traceability of all significant actions. Standards like SOX require a minimum of 7 years of audit data retention. Institutions typically face quarterly internal audits and annual external or regulatory audits.

The cost of incomplete audit trails is significant:

* **Regulatory fines** for failure to demonstrate compliance during audits
* **Extended audit timelines** when auditors can't find the evidence they need
* **Reputational risk** when gaps in traceability raise questions about operational controls
* **Remediation costs** for retroactively reconstructing activity that wasn't properly logged

Flowker eliminates these risks by capturing audit data automatically, at every step, with no manual instrumentation required.

## What Flowker captures

***

Flowker's audit system records every significant event across the platform:

* **Workflow lifecycle events** — creation, activation, deactivation, updates, and deletion of workflows
* **Execution events** — when a workflow execution starts, completes, or fails
* **Provider call events** — every request to an external provider, including response status and timing
* **Provider configuration changes** — creation, updates, and deletion of provider configurations

Each audit entry includes:

* **Timestamp** — when the event occurred
* **Actor identification** — who or what initiated the action
* **Action type** — what operation was performed
* **Affected resources** — which workflows, executions, or configurations were involved

<Note>
  Audit logs are immutable. Once written, entries cannot be edited or deleted — providing a tamper-proof record for regulatory purposes.
</Note>

## Hash chain integrity

***

Every audit entry includes a cryptographic hash computed from its contents and the hash of the previous entry, forming a chain. This means any tampering with historical records breaks the chain and is immediately detectable.

You can verify the integrity of the audit trail up to any specific event using the [Verify hash chain](/en/reference/flowker/verify-audit-hash-chain) endpoint. The response tells you whether the chain is intact and, if not, identifies the first broken entry.

## Querying audit events

***

Flowker provides flexible search capabilities for audit data, designed for the questions compliance teams actually ask:

* **By event type** — filter by specific operations (`WORKFLOW_CREATED`, `EXECUTION_STARTED`, etc.)
* **By action** — filter by what was done (`CREATE`, `UPDATE`, `DELETE`, `EXECUTE`, etc.)
* **By result** — show only successes or failures
* **By resource type** — narrow to workflows, executions, or provider configurations
* **By resource ID** — drill into a specific resource's audit history
* **By date range** — examine activity during a specific audit period

Search results use cursor-based pagination, ensuring consistent results even as new audit events are being recorded.

To retrieve a specific event by ID — for example, when investigating an incident or following up on an alert — use the [Get audit event](/en/reference/flowker/get-audit-event-by-id) endpoint (`GET /v1/audit-events/{id}`).

See the [Search audit events](/en/reference/flowker/search-audit-events) endpoint for the full API reference.

## Validation before the ledger

***

The most powerful compliance feature in Flowker isn't the audit trail itself — it's the architecture that makes the audit trail meaningful.

Flowker enforces all validation checks **before** any data reaches the ledger. This means:

* Every transaction that enters your ledger has passed every required check
* There are no compliance gaps from transactions that were validated after the fact
* Rollbacks due to failed post-write validation are eliminated
* Auditors can see a clear, unbroken chain: validation passed, then ledger write occurred

This validation-before-ledger model is the foundation of Flowker's compliance proposition. It doesn't just log what happened — it ensures that only validated, compliant transactions ever make it into your system of record.

## What's next

***

<CardGroup cols={2}>
  <Card title="Security" icon="shield" href="/en/flowker/security">
    Learn about Flowker's authentication model, encryption, and resilience features.
  </Card>

  <Card title="Audit events API" icon="magnifying-glass" href="/en/reference/flowker/search-audit-events">
    Search and verify audit data through the API.
  </Card>
</CardGroup>