Flows as code, from scripts and CI

API tokens

Project owners make tokens under API tokens in the project’s top bar. A token belongs to one project and has scopes:

• The token is shown once and stored as a hash. It can expire after 30, 90 or 365 days, and be limited to an address range, such as your CI runners’.
• A token works on the API only: never on the app’s own routes, billing, members or other tokens.
• It stops working when it’s revoked, when it expires, when the person who made it loses access to the project, and when the project moves to another organization. Organization owners see and revoke every token of their projects.
• Runs started with a token count towards the plan’s flow runs, like any run.

The API

JSON over HTTPS at https://journeylanes.com/api/v1, with the token as Authorization: Bearer jlt_…. The reference is an OpenAPI 3.1 document: /api/v1/openapi.json. Errors are { "error": { "code", "message" } }, and within version 1 fields are only added, never renamed or removed.

curl -s -X POST https://journeylanes.com/api/v1/flows/<flow>/runs   -H "Authorization: Bearer $JOURNEY_LANES_TOKEN"   -H "Content-Type: application/json" -d '{"environment": "Acceptance"}'

A run answers at once with its id; poll GET /api/v1/runs/<id> until its status is passed or failed, and read its report. Leave out the environment to run on the mock. One thing runs at a time per project, and each token makes at most 300 calls a minute.

Flows in your repository

Put flow files in .journeylanes/flows/ of a repository you’ve added, one <name>.flow.json per flow, in the same format as Export → Flow file. Every scan of the repository reads them: a new file adds a flow, a changed file updates it, and a removed file archives its flow (kept, no longer monitored). A file is found again by its id, or else its file name, so renaming a file with an id keeps the flow and its run history.

Files are checked like an import; one that doesn’t pass is named in the scan’s notice and leaves its flow as it was. Flows from a repository are edited in the repository: the app shows them read-only, with From repository next to the name. An owner can detach one to edit it in the app instead. Monitoring is set in the app either way.

Command line

journeylanes is a single file you run with Bun, without other dependencies. It reads JOURNEY_LANES_URL and JOURNEY_LANES_TOKEN.

curl -fsSLO https://journeylanes.com/cli/journeylanes.ts
curl -fsSLO https://journeylanes.com/cli/journeylanes.ts.sha256 && sha256sum -c journeylanes.ts.sha256
JOURNEY_LANES_URL=https://journeylanes.com JOURNEY_LANES_TOKEN=jlt_… bun journeylanes.ts run --all --wait

Check the file before you run it: sha256sum -c stops when it doesn’t match. The SHA-256 of the CLI this installation serves now is e223ac354bfb2f700b521d06cc7889e811411cda0524835e720e2f2af61b4a92; it changes when the CLI does. In CI, pin that value instead of downloading the checksum next to the file.

GitHub Action

The action runs the CLI in a job, adds a summary of the runs to the job page, and fails the job when a flow fails. Until it is in the GitHub Marketplace, run the CLI in a step of your own:

- uses: oven-sh/setup-bun@v2
- run: |
    curl -fsSLO https://journeylanes.com/cli/journeylanes.ts
    echo "e223ac354bfb2f700b521d06cc7889e811411cda0524835e720e2f2af61b4a92  journeylanes.ts" | sha256sum -c -
    bun journeylanes.ts run --all --wait --env Acceptance
  env:
    JOURNEY_LANES_URL: https://journeylanes.com
    JOURNEY_LANES_TOKEN: ${{ secrets.JOURNEY_LANES_TOKEN }}

In GitHub Actions the CLI adds the run summary to the job by itself. A packaged action that does the same, with inputs for the flows and the environment, is on its way to the GitHub Marketplace. It downloads nothing: it carries its own copy of the CLI, so pinning the action by its commit SHA pins the code that runs.

- uses: <the published action>@v1
  with:
    url: https://journeylanes.com
    token: ${{ secrets.JOURNEY_LANES_TOKEN }}
    environment: Acceptance

For a check after every deploy without a GitHub workflow, use a deploy hook.