Main: API Testing

Updated

Main: API Testing

Overview

Use this page to understand how API testing works on the LoadGen platform before you build your first flow. The API Testing overview is the informational front door for the API testing area, sitting in the Main section of the navigation menu alongside the other module overviews. It draws the moving parts as one diagram, sequences the work as a lifecycle, and links into the pages where each piece is configured.

API testing answers the question "does the interface still behave?" at a level below the user interface. A flow is a directed graph of API request nodes, so you can validate multi-step behaviour that a single-request tool cannot cover: sign in, capture a bearer token, call a protected endpoint, assert on the response. The business value is catching contract regressions early, and being told which of your flows an API change actually breaks rather than discovering it in production.

This page changes nothing and requires no configuration to open. The capability cards are navigation into the API Testing pages, and those pages keep their own licence and role gates.

Main: API Testing, full page

Key concepts

  • Flow - A directed graph of API request nodes that executes a defined sequence of HTTP calls. Flows are the unit of execution in this module and can be built from scratch, from built-in templates, or by import. (related: API Testing: Flows)
  • API source - A registered OpenAPI (Swagger) specification. LoadGen fetches the spec, stores each retrieval as a versioned snapshot, records the differences between versions, and reports which flows are impacted by a change. (related: API Testing: API Sources)
  • Environment - A named bundle of base URL, request headers, allowed hosts, and reusable variables for one target system, so the same flow runs against development, staging, or production without editing it. (related: API Testing: Environments)
  • Auth profile - Reusable stored credentials, a Bearer token, an API key, or an OAuth2 client configuration, injected into each request at run time instead of being repeated per flow. (related: API Testing: Auth Profiles)
  • Committed revision - The stable version of a flow that scheduled runs execute. A schedule only runs flows that have been committed, so work in progress cannot fire unattended. (related: API Testing: Schedules)

When to use it

  • When you are about to build your first API flow and want to see how sources, environments, auth, and schedules relate.
  • When you need to explain how LoadGen detects an API change and traces it to the flows it affects.
  • When you are deciding where a value belongs: in the flow, in an environment variable, or in an auth profile.
  • When you want unattended API health checks and need to know what has to exist before a schedule will fire.
  • When a scheduled flow is not running and you want to re-check the prerequisite chain from one place.
  • When you want a launch point into Flows, API Sources, Environments, Auth Profiles, Schedules, or Run History.

Before you begin

  • No prerequisites for opening this page. It is informational and ungated.
  • Using the module requires the API Testing licence module (LG061). Without it, the API Testing pages show an activation card instead of the feature. Check your entitlement on Infrastructure: Licensing.
  • Building flows against a specification requires at least one registered source on API Testing: API Sources.
  • Executing a flow requires at least one environment defined on API Testing: Environments.
  • Scheduled execution additionally requires the flow to have a committed revision.

Steps

Step 1

Open API Testing in the Main section of the left navigation menu.

Expected result: The overview page opens immediately, with the architecture hero at the top. It renders on an appliance with no sources, environments, or flows configured yet.

Step 2

Read the architecture hero.

The diagram shows the platform issuing HTTP calls against your API endpoints, and where the supporting objects attach: the OpenAPI source that describes the API, the environment that supplies the base URL and variables, and the auth profile that supplies credentials. Quantities drawn inside the diagram are illustrative and prefixed e.g.; they do not read your configuration.

Main: API Testing, architecture hero

Main: API Testing, lifecycle strip

Step 3

Follow the lifecycle strip.

The strip lays API testing out as six ordered steps. The underlying chain, as documented across the API Testing pages, is:

  1. Register a source. Point LoadGen at your OpenAPI document on API Testing: API Sources. LoadGen snapshots each retrieval and diffs versions.
  2. Define an environment. Set the base URL, headers, allowed hosts, and variables per target system on API Testing: Environments.
  3. Store credentials once. Create Bearer, API key, or OAuth2 profiles on API Testing: Auth Profiles, optionally linked to Configuration: Credential Profiles.
  4. Build the flow. Chain the request nodes on API Testing: Flows, from scratch, from a template, or by import.
  5. Automate it. Attach a cron schedule on API Testing: Schedules, with optional environment and auth overrides and linked alert profiles.
  6. Review outcomes. Read the execution log on API Testing: Run History, where retention is shown as a chip that links to its setting.

The page's lifecycle strip, From spec to safety net, in six steps, reads: 1 Import (an OpenAPI source), 2 Compose (chain the steps), 3 Bind (environment + auth), 4 Dry run (watch each step), 5 Schedule (cron, 5 min to weekly), 6 Triage (debug mode + artifacts). The numbered list above expands those labels (verified).

Step 4

Use the capability cards to enter the module.

Each card names one thing API testing does and links to the page where you do it. Selecting a card is read-only navigation; no flow is run and no object is created from this page.

Main: API Testing, capability cards

Step 5

Read the pulse chips, if present.

Where the platform holds a reliable count, such as the number of configured flows, the page surfaces it as a small live chip. Treat these as orientation only; the module pages are the authority for anything you intend to act on.

Next steps

  • Starting from nothing? Register your specification on API Testing: API Sources, then define an environment.
  • Ready to build? Go to API Testing: Flows and start from a template if the API is unfamiliar.
  • Want it to run unattended? Commit the flow to a stable revision, then create a cron schedule on API Testing: Schedules.
  • Want to be told when it fails? Attach an alert profile from Alerting: Profiles to the schedule. Linked profiles are evaluated on the run's terminal outcome, after any retries.
  • History growing too large? Tune the policy on Configuration: API Testing: Retention.
  • Want to see the whole platform, not just this module? Open Main: Platform Map.

Verify the result

The page is working correctly when the architecture hero renders as a diagram, the lifecycle strip shows its steps, and the capability cards navigate into the API Testing pages. Nothing is saved here, so there is no state to confirm. If a capability card opens a page showing an activation card instead of the feature, that is the target page's licence gate rather than a fault on this page.

Troubleshooting

  • Symptom: A capability card opens a page showing an activation card with Activate License and Learn More. Fix: API Testing (LG061) is not licensed on this appliance. Check Infrastructure: Licensing. This overview page is ungated by design and describes the module regardless.
  • Symptom: The lifecycle mentions a Retention page you cannot see in the navigation menu. Fix: CONFIGURATION: API TESTING is an Expert-mode section; switch the sidebar footer toggle to Expert.
  • Symptom: A schedule exists and is enabled but never runs the flow. Fix: Schedules only execute flows committed to a stable revision. Commit the flow on API Testing: Flows.
  • Symptom: A flow suddenly fails after the API changed. Fix: Refresh the source on API Testing: API Sources and use the Impacted Flows column to reach the affected flows and migrate them.
  • Symptom: A manual Run now does not raise an alert. Fix: That is intended. Linked alert profiles are evaluated only for scheduled runs reaching a terminal outcome, never for a manual run.
Was this article helpful?
0 out of 0 found this helpful