Skip to main content
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

Flowker

The workflow orchestration platform. It coordinates the steps around a transaction: anti-fraud checks, calls to external approval systems, payment routing, and customer onboarding.

Midaz and Tracer as providers

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.

Console

The Flowker module. Operators create and edit workflows, configure providers, and monitor executions.

Access Manager

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

  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

​
Adopt it one piece at a time

1

Start with your own services

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.
2

Add the native providers

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.
3

Put webhook access under Access Manager

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.
4

Enable the Console module and export telemetry

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

What is Flowker?

Read what the platform coordinates, and the records it keeps for each execution.

Getting started with Flowker

Set up Flowker and run your first workflow end to end.

Core concepts

Learn workflows, nodes, edges, the catalog, provider configurations, and executions.