Quick Start

Build one runnable request-step scenario around GET /orders/{id}, run it, and confirm you can read the report before moving into correlation-specific features.

What this page helps you do

What this page helps you do

Build one runnable request-step scenario, run it, and confirm that the report shows the first path clearly.

Who this is for

Evaluators and implementers who want the shortest route from install to a real LoadStrike result.

Prerequisites

  • A supported SDK package installed
  • A valid runner key before the run starts
  • An HTTP endpoint you can call with a simple GET request

By the end

A runnable first scenario and a report you can inspect with confidence before adding more SDK surfaces.

Choose this path when

Use quick start when your goal is the smallest runnable LoadStrike scenario before you decide whether the workload needs correlation-specific modeling.

Visual guide

Quick start sequence from SDK install to a GET request step, run execution, and report review.
The quickest evaluation path is one named GET request step, one runner-backed scenario, and one report you can read before adding correlation.

Guide

What this page helps you do

Use this quick start when you want the smallest LoadStrike setup that can call GET /orders/{id}, record the result as one named step, and produce a report you can inspect immediately.

When to use this path

This is the right starting point when you need to validate scenario shape, runner setup, and report reading before you add correlation-specific source and destination definitions.

What to keep simple

Start with one plain HTTP request, one named step, and one small load simulation. That keeps the first run focused on the core scenario model instead of transport-specific endpoint configuration.

How execution starts

Register the scenario, add a valid runner key in code or config, and run. Once that baseline works, move to the transaction concept page when the workload needs cross-system completion tracking.

Getting started samples

Use these samples to compare how each supported SDK wires one first request-step scenario around GET /orders/{id}, runner setup, and the first report output.

If you run these examples locally, add a valid runner key before execution starts. Set it with WithRunnerKey("...") or the config key LoadStrike:RunnerKey.

Quick Start

using LoadStrike;

var httpClient = new HttpClient
{
    BaseAddress = new Uri("https://api.example.com")
};

var scenario = LoadStrikeScenario.Create("read-order", async context =>
{
    var orderId = $"ord-{context.InvocationNumber}";

    var step = await LoadStrikeStep.Run<string>("GET /orders/{id}", context, async () =>
    {
        using var response = await httpClient.GetAsync($"/orders/{orderId}");

        return response.IsSuccessStatusCode
            ? LoadStrikeResponse.Ok<string>(statusCode: ((int)response.StatusCode).ToString())
            : LoadStrikeResponse.Fail<string>(
                statusCode: ((int)response.StatusCode).ToString(),
                message: "Order lookup failed");
    });

    return step.AsReply();
})
.WithLoadSimulations(
    LoadStrikeSimulation.Inject(10, TimeSpan.FromSeconds(1), TimeSpan.FromSeconds(20))
);

LoadStrikeRunner.RegisterScenarios(scenario)
    .WithRunnerKey("rkl_your_local_runner_key")
    .Run();

Quick Start Parts

Scenario

Starts with one plain request-step scenario before you add transport-specific tracking surfaces.

GET step

Uses GET /orders/{id} so the first example stays focused on scenario shape, naming, and status handling.

Simulation

Adds one small inject profile so the example is runnable without introducing a larger load plan first.

Runner execution

Registers the scenario, applies the runner key, and starts the run with reports enabled.