> ## 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.
# Orchestration engine
> Coordinate the checks and approvals around a transaction, with a step-level record of what ran and what it returned.
Financial operations involve multiple steps, approvals, and external checks. When you write custom logic for each flow, the same rules spread across your services, and errors, delays, and compliance gaps follow. Flowker holds that logic in one place. You define the process once as a graph of nodes and edges, and Flowker runs it the same way every time. Your fraud vendor, your KYC service, Tracer, and the Midaz ledger are nodes in that graph.
The `stepResults` field contains one entry for each executed executor, conditional, or action node, in order. Entries report status and duration, can include output, and failed steps can include `errorMessage`. Trigger nodes create no step record.
## What you get
***
The workflow orchestration platform. It coordinates the steps around a transaction: anti-fraud checks, calls to external approval systems, payment routing, and customer onboarding.
The catalog registers Midaz as the `ledger` provider and Tracer as the `tracer` provider, both synthesized from their OpenAPI specifications. A workflow node calls their operations.
The Flowker module. Operators create and edit workflows, configure providers, and monitor executions.
With `PLUGIN_AUTH_ENABLED=true`, every call to a webhook trigger requires a bearer token, and the caller needs the `execute` permission on the `webhooks` resource.
## How the pieces fit together
***
```mermaid theme={null}
flowchart LR
Trigger["Trigger
your webhook call or a schedule"]
Flow["Flowker
a graph of nodes and edges"]
Yours["Your services
KYC, AML, fraud score"]
Tracer["Tracer
allow, deny, or review"]
Midaz["Midaz ledger
records the transaction"]
Console["Console
Flowker module"]
AM["Access Manager
issues the tokens"]
Trigger -->|"starts an execution"| Flow
Flow -->|"generic HTTP connector"| Yours
Flow -->|"native provider tracer"| Tracer
Flow -->|"native provider ledger"| Midaz
Console -->|"reads workflows and executions"| Flow
AM -.->|"bearer token, execute on webhooks"| Trigger
classDef lerian fill:#fff8e1,stroke:#f4b400,color:#333;
classDef yours fill:#e8f0fe,stroke:#4285f4,color:#333;
classDef ext fill:#f1f3f4,stroke:#9aa0a6,color:#333;
class Flow,Tracer,Midaz,Console,AM lerian;
class Trigger,Yours yours;
```
1. A webhook call or a schedule starts an execution. Only one active workflow registers each path and method combination.
2. Executor nodes call your services through provider configurations.
3. A conditional node evaluates its condition and returns one named outcome. Flowker follows the outgoing edge that carries that name.
4. A `tracer` node asks Tracer for a decision. A `ledger` node calls Midaz. Both providers appear when the native schema registry is configured and synthesis succeeds.
5. The `stepResults` field contains one entry for each executed executor, conditional, or action node, in order. Entries report status and duration, can include output, and failed steps can include `errorMessage`. Trigger nodes create no step record.
6. Operators read the execution in the Console's Flowker module.
Flowker retries an executor call that fails on a transient error. It does not retry a `POST` or a `PATCH` by default. A circuit breaker guards each provider. It opens after 20 consecutive failures, waits 30 seconds, then allows one request to test the service.
Flowker orchestrates the checks that come before a ledger-posting step. It does not police the boundary at the ledger itself. Your ledger integration must enforce that no other path can post without the required checks.
## What each piece owns
***
| Piece | Source of truth for | Talks to | You keep |
| -------------- | ------------------------------------------------------------------------------ | ---------------------------------------------------- | -------------------------------------------------------------------------- |
| Flowker | workflow definitions, executions, provider configurations, the schema registry | your services, Tracer, Midaz | the flow logic in one place |
| Tracer | the allow, deny, or review decision | an executor node that calls it | your rules and spending limits |
| Midaz | the transaction it records | an executor node that calls it | your ledger. Flowker does not enforce that every posting passed the checks |
| Access Manager | who may execute a webhook trigger | Flowker, on every protected route | your users and your machine-to-machine applications |
| Console | the execution record an operator reads | the Flowker module | one login for operators |
| Your services | KYC, AML, fraud scoring, approvals | the generic HTTP connector, over the hosts you allow | your vendors and your contracts |
## Adopt it one piece at a time
***
Create one provider configuration for each service instance you call. It holds the base URL, the credentials, and the public hosts the connection may reach. The generic HTTP connector rejects an empty `allowedHosts` list.
Set `MIDAZ_BASE_URL` and `TRACER_BASE_URL` in the deployment. An empty `OPENAPI_NATIVE_PROVIDERS` makes every native provider eligible for synthesis. A non-empty list narrows eligibility to the ids you name.
With `PLUGIN_AUTH_ENABLED=true`, every request to a webhook path needs a bearer token, and the caller needs `execute` on `webhooks`. Grant that permission to a machine-to-machine identity for each system you let call your webhooks.
Enable the Flowker module in the Console, where operators read workflows and executions. Set `ENABLE_TELEMETRY=true` and an OTLP endpoint to export telemetry to your own collector.
## Bring your own
***
* **Any ledger.** Flowker calls Midaz or another ledger through a provider configuration. It requires no particular ledger.
* **Your KYC, AML, and fraud vendors.** The generic HTTP connector calls them over the public hosts you list on the connection.
* **Your own API.** Upload its OpenAPI document to the schema registry. Point a provider configuration at that document. A node then calls one operation of your API.
* **Your triggers.** You register a webhook path, or you set a cron cadence with the timezone you name.
* **Your observability backend.** When you enable telemetry, Flowker emits OpenTelemetry data for its HTTP and service operations to the collector you run.
## A worked example
***
The catalog ships a template that validates a transaction through Tracer and creates it in Midaz when Tracer approves. This example adds a KYC check in front of that pair.
1. Your payment service posts the request to the webhook path that the workflow registers.
2. An executor node calls your KYC service through its provider configuration.
3. A conditional node reads the KYC result and routes a failed check to a rejection path.
4. An executor node sends the payload to Tracer through the `tracer` provider.
5. When Tracer approves the transaction, a `ledger` node creates it in Midaz.
6. The webhook answers your service in the response mode you chose. The default returns a `202` receipt, and `sync` waits for the outcome.
## Start here
***
Read what the platform coordinates, and the records it keeps for each execution.
Set up Flowker and run your first workflow end to end.
Learn workflows, nodes, edges, the catalog, provider configurations, and executions.