From a sentence about your users to a flow that keeps checking itself

Repository scanning

Add a GitHub repository to a project and Flow Creator reads the files that matter for a journey. Private repositories need a fine-grained token with read access to contents; it is stored encrypted.

• Endpoints from OpenAPI and Swagger specs and from route code: Express, Elysia, Hono, Fastify, NestJS, Symfony, Laravel and FastAPI.
• Records from Prisma, Doctrine, TypeScript interfaces and OpenAPI schemas.
• Roles and sign-in from Keycloak realm and client settings, realm exports and role checks, including Symfony role hierarchies, so a super admin inherits what a company admin may do.
• Pages from React Router frontends: route trees, route objects and file routes, each with a name and the API calls it makes.

A frontend and its API can be separate repositories in one project. A page’s call finds its endpoint even when parameter names differ or the frontend leaves out a prefix its HTTP client adds.

Flows from a description

Write who signs in, what they see and what they can do. Each role becomes a lane, each action a step that calls a real endpoint from the scan, and a system lane shows the records each step touches.

Flow Creator turns descriptions into flows with its own rules, with no AI needed. With an Anthropic API key, Claude can draft flows from longer or looser descriptions; the result is the same kind of flow, and you can edit every step.

Tours per role

Instead of describing a journey, pick one of the roles the scan found. The tour shows each kind of record that role may work with, with its actions underneath, and adds up to five things the role may not do, each with a check that the call is refused.

Deletes are never part of a tour, so running one never removes data. When the code leaves a decision to runtime logic, the tour says which endpoints it left out.

Mock backend

Every project gets its own mock at /mock/<project>, ready as soon as a repository is scanned:

• Keycloak-shaped sign-in: password and refresh token grants, user info and discovery.
• REST over generated records shaped by your entities: list, get, create, update, delete, nested routes and assignments.
• Tokens carry the role’s permissions and, for scoped roles, the records they may see. A company admin only gets their own companies; anything else answers 403.
• Records live in Postgres, so a load test against the mock exercises a real database.

Your own frontend or Postman can use the mock too, and all of its traffic streams to the console in Flow Creator.

Runs and step checks

Running a flow walks its steps in order, fills in ids from earlier responses, and builds request bodies from your entities. The canvas shows each step pass or fail as it happens.

Every request and sign-in step can carry checks:

• Status: “is 200”, or “is 403” for a step that must be refused.
• Response time: “within 500 ms”.
• Response fields: total equals 2, items has more than 0 entries, id exists.

Flows drawn from a description get the checks the description promises.

Live environments

Next to the mock, add your test, acceptance or production environments. Each has an API address, a way to sign in, and credentials per role.

Writes and load tests are off per environment until you allow them. “Test connection” signs every role in and shows the roles in each token.

Monitoring and alerts

Choose an interval and Flow Creator re-runs the flow, recording pass rate and how long runs take. When a flow fails a set number of runs in a row, every channel gets one alert naming the failing step and the failed checks. One more follows when it passes again; nothing is sent in between.

Channels: email, Microsoft Teams, Slack and webhooks.

Deploy checks

Give an environment a deploy hook and call it from your CI or Argo CD after a deploy. The flows you chose run one after another, a failure always alerts, and with a repository and commit Flow Creator sets a GitHub commit status. The hook has its own token per environment, so CI needs no user account.

Load tests

Repeat one step of a flow many times, with a number of requests in flight at once. The steps before it run once to sign in and collect ids. Throughput and p95 stream live, and afterwards the test checks:

• error rate and p95 against your limits;
• that the collection grew by exactly the number of successful creates;
• that no record points at a missing one;
• that a scoped role only wrote inside its scope;
• that the whole flow still passes.

Access audit

Every role from your flows signs in and probes every endpoint, along with a caller without a token:

• with its own ids, which should work if the role may do this;
• with ids only other roles can see, which should be refused (insecure direct object references and cross-tenant reads, updates and deletes);
• with writes that point at another tenant, which should be refused;
• with lists, which must only return the role’s own tenant;
• without a token, which should answer 401.

Findings are ranked from critical to “needs a decision”. What you decide becomes the project’s access policy, which the mock then enforces. On the mock, data is restored after every probe; on live environments the audit never sends delete probes.

Teams and roles

Organizations hold projects and the people who work on them. In a project, viewers see flows, runs and audits; editors also connect repositories, edit and run flows; owners also manage members and the GitHub token. Invites go by email, and people outside a project get a plain “not found”.