Live environments

The same flows against your test, acceptance and production environments

An environment is an API address, a way to sign in, and a test account per role. Writes and load tests stay off until you allow them, per environment.

Environments

Next to the built-in mock, owners add environments with an API URL, a sign-in type and credentials per role. Two opt-ins guard each one: Allow writes (off: create, update and assign steps are skipped) and Allow load tests. “Test connection” signs every role in and shows the roles and groups in each token.

Services can each have their own address, and a step goes to the service whose scanned code defines its endpoint. Runs, monitors, step checks, load tests and the access audit all follow the selected environment.

Sign-in types

TypeForPer role
OAuth password grantKeycloak, Auth0, Entra ID and Azure AD B2C test usersUsername and password
OAuth client credentialsService accountsClient id and secret
Login requestJSON or form logins: Symfony LexikJWT, Laravel Sanctum, Django sessions, Magento, Supabase, Firebase, AWS Cognito and your ownUsername and password, optional two-factor secret
Login page (code + PKCE)Clients that only allow the browser login, plain HTML or Keycloakify themesUsername and password, optional two-factor secret
StaticAPI keys, fixed bearer tokens, HTTP BasicKey, token, or username and password

Presets fill in Auth0, Microsoft Entra ID, Azure AD B2C, Supabase, Firebase Authentication, AWS Cognito, Laravel Sanctum, Django session, Magento and WordPress, each with a note on what to check. OAuth types take extra token fields, such as Auth0’s audience or Entra’s resource.

A login request can read its token from the reply body, a header or a session cookie, keep and renew cookies, fetch a CSRF token first and send it with writes, and call a refresh endpoint.

Two-factor and passkeys

  • TOTP: codes computed from the account’s secret (base32 or an otpauth:// URI).
  • Emailed code: read from a test inbox (Mailpit or Mailtrap) with a pattern.
  • Texted code: read from the messages of a Twilio test number.
  • Fixed code: for a staging environment that accepts one code for every test account.
  • Passkeys (WebAuthn): Journey Lanes acts as the authenticator, with a key per role registered once and stored encrypted; as the sign-in or as a second factor.

CAPTCHAs are not solved. On staging, use the provider’s test keys, or let test accounts skip them.

Login pages and single sign-on

A login page sign-in does what a browser does: it opens the identity provider’s page, fills in the account (and a TOTP code when asked), follows the redirects and reads the code from the redirect back, without opening it. Pages that submit a form on their own are followed too: SAML with the HTTP-POST binding, WS-Federation and OIDC form_post, so a Keycloak, Auth0 or Entra that brokers another provider signs in across them. Login page parameters such as kc_idp_hint, connection or domain_hint pick the provider.

A real browser. Login pages that only appear once their JavaScript runs (Microsoft Entra and B2C, Okta, Auth0’s Universal Login, Cognito’s managed login, single-page apps) are opened by this installation’s sign-in browser. Every sign-in gets a Chromium process of its own that is closed afterwards, all of its traffic goes through a proxy that applies the same address rules as every other call, and a sign-in is ended at its deadline whatever the page does. Consent pages are never approved and bot detection is never worked around.

Personal Google, Apple and Microsoft accounts refuse automated sign-in by design. For those, a role uses a saved sign-in: a refresh token or session cookies pasted once, stored encrypted, and kept current as the identity provider rotates them, with one alert when it stops working.

Headers

An environment can send extra headers with its sign-ins, its requests or both: an API gateway’s key (Supabase’s apikey, Azure’s Ocp-Apim-Subscription-Key), or a device id and app version for a mobile API. Steps can add headers of their own. Secret values are stored encrypted, and run history shows only header names.

What a run does

A run walks the steps in dependency order, fills path keys from earlier replies and builds bodies from your entities. The canvas shows each step pass or fail as it happens.

  • Refusals are steps like any other: a step that expects 403 passes when the API refuses.
  • Uploads: multipart/form-data with generated test files (PNG, PDF, CSV, text or random bytes up to 5 MB).
  • GraphQL and gRPC steps, including gRPC streaming and gRPC-Web.
  • Repeat until its checks pass: a read polled every few seconds for up to five minutes, for a background job, a webhook’s effect or a payment that settles.
  • Clean-up steps run last, also when earlier steps failed, and skip themselves when there is nothing of theirs to remove.
  • Rate limits: a 429, or a 503 with Retry-After, is waited out and retried within fixed bounds; load tests don’t retry.
  • Signing in by a request: a step can take the token or cookies a reply hands out, which with an email step covers magic links and one-time codes.

Flows that make their own data

On a shared acceptance environment names and email addresses can’t be reused. Every run has its own {{run.id}}, {{run.time}} and {{run.password}}; email steps read invitations and links from the environment’s test inbox; and a role’s test account can use the run’s values, so a flow can create a user, accept the invitation and carry on as that user. Passwords and values read from emails are masked in run history.

Reaching your environment

Journey Lanes calls public addresses only, and checks every address before each call. Calls from this installation come from 88.198.26.110: add it to your staging firewall’s allow list if it only lets known addresses in. For an environment on a private network or behind a VPN, run a relay agent in that network.

Next: Checks, audits and load tests

Point a flow at your test environment

Add the address, choose a sign-in preset, and give each role a test account.