How to Use URL Query Parameters

Adding query parameters to a request

You can add query parameters to your request either in the URL or in the Query Params list.

https://www.example.com?query1=value1&query2=value2
https://api.example.com/v2/resources/1?query1=value1&query2=value2

Both methods are valid and stay in sync: parameters you type into the URL appear in the Query Params list, and parameters you add in the list are appended to the URL. The request is sent with the parameters in that list.

Why query parameters matter in a load test

Query parameters are part of the request URL, so the server (and anything in front of it, like a CDN, reverse proxy, or WAF) sees them as part of what it is being asked for. This matters in two ways during a load test:

• Routing and filtering: many APIs use query parameters to select a resource, page, or filter (?page=2, ?status=active, ?locale=en). If your test only ever hits one combination of parameters, you are only testing one code path. A search endpoint that is fast for ?q=shoes might behave very differently for ?q= (empty) or a query with many filters applied at once.
• Caching: a CDN or reverse proxy commonly treats the full URL, including its query string, as the cache key. Adding a query parameter that changes on every request (a cache-busting timestamp, a random id) can accidentally turn a cacheable endpoint into one that misses cache on every single virtual user. That will look like a much slower, much more loaded backend than production traffic would ever produce, when the real cause is the query string itself.

Static parameters vs. per-request values

The parameters you type into a test request are static: every virtual user sends the exact same query string on every iteration. That is fine for most conceptual testing (verifying an endpoint behaves correctly and stays fast under load), but keep two things in mind:

• You cannot make a query parameter "global" and have it apply automatically to every request in the test, for example an API key passed as ?api_key=.... It needs to be added to every request URL (or Query Parameters field) individually, wherever it's required.
• If the endpoint you're testing expects a different value per call, a pagination cursor, a unique order id, a one-time token, a fixed query string will only exercise that single value, repeated. Real traffic hits many different values, so results based on one static value tell you about that one case, not the full range of production behavior.

Common pitfalls

• Forgetting to URL-encode: LoadFocus adds your parameters to the request as you typed them, so spaces, &, =, and other reserved characters inside a value need to be percent-encoded by you (for example %26 for &). Otherwise the server reads them as separators and sees extra parameters instead of a single value.
• Confusing the fragment with a parameter: anything after # (like #hash1 in https://www.example.com?query1=value1#hash1) is a URL fragment, not a query parameter. Fragments are never sent to the server, and LoadFocus drops them from the request, so they have no effect on a load test.
• Listing the same key twice: every row in the Query Params list is sent, so adding query1 twice sends it twice, which can trigger different, and unintended, behavior on servers that only expect one value per key.

For related guidance, see What is a valid URL for a load test and Query Parameters.