canonical: https://jentic.com/apis/loader.io/loader-io

# Loader.io API

Jentic publishes the only available OpenAPI specification for Loader.io API, keeping it validated and agent-ready. Loader.io is a cloud-based load testing service from SendGrid Labs that lets engineering teams simulate concurrent traffic against web endpoints. The API supports the full test lifecycle: register an application, verify domain ownership, create and run load tests, monitor progress, and pull historical results. It also exposes the loader.io egress IP list for firewall allowlisting.

## For AI agents

Register applications, verify test domains, run cloud-based load tests, and retrieve performance results from the Loader.io API.

## Scope

Does not handle application performance monitoring, error tracking, or synthetic transaction monitoring - use for cloud load test orchestration only.

## Capabilities

- Register applications and verify domain ownership before running load tests
- Create load tests with target URLs, concurrency, and duration configuration
- Trigger and stop test runs from CI or agent workflows
- Retrieve historical results for any test, including per-run breakdowns
- Pull the loader.io egress IP list to allowlist test traffic at the firewall
- Delete obsolete applications from the account once retired

## Use cases

### Pre-Release Load Test in CI

Engineering teams gate releases on a load test against staging. Loader.io is called from CI to verify the application, kick off a configured test, wait for the run to finish, and pull the result. Failures fail the pipeline. The flow is small enough to wire into any CI provider with a few API calls.

Example prompt: Call PUT `/tests/{test_id}/run` to start a saved load test, poll GET `/tests/{test_id}/results` until the run completes, and fail the build if response time exceeds the threshold.

### Domain Verification and Firewall Setup

Before any test can run, loader.io requires you to prove ownership of the target domain and ideally allowlist the loader.io egress IPs at your firewall. The API exposes both: a verification endpoint per app and a global servers endpoint that returns the IP list. This means platform teams can fully script onboarding instead of doing it through the dashboard.

Example prompt: Call POST /apps to register the domain, POST `/apps/{app_id}/verify` to verify ownership, then GET /servers to retrieve the loader.io IPs for the firewall.

### AI Agent-Driven Performance Triage

An AI agent investigating a slow endpoint can use Jentic to discover Loader.io operations, configure a test against the suspect URL, run it, and pull the results back into a triage summary. Credentials remain in your Jentic One instance, so the agent can run tests without ever holding the API key.

Example prompt: Use Jentic to call POST /tests with a config targeting the slow URL, PUT `/tests/{test_id}/run` to start it, and GET `/tests/{test_id}/results` to summarise latency and error rate.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/apps` | Register an application or domain |
| POST | `/apps/{app_id}/verify` | Verify domain ownership |
| POST | `/tests` | Create a load test configuration |
| PUT | `/tests/{test_id}/run` | Trigger a test run |
| PUT | `/tests/{test_id}/stop` | Stop a running test |
| GET | `/tests/{test_id}/results` | Retrieve results for a test |
| GET | `/servers` | Loader.io egress IPs |

## Key resources

- **Apps** — Register and verify the applications and domains being tested
- **Tests** — Create, run, stop, and retrieve results for load tests
- **Results** — Historical and per-run results for any test
- **Servers** — Loader.io egress IPs for firewall allowlisting

## Why Jentic

- **Setup:** Wiring the Loader.io API by hand means setting up its loaderio-auth header, verifying an app before testing it, and handling retries yourself against api.loader.io. Through Jentic you install once, import the Loader.io API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** Loader.io puts the app and test ids in the URL path (`/apps/{app_id}/verify`, `/tests/{test_id}/run`), so a rule can pin your agent to one test: it can run and read results for that test and nothing else. You choose the operations it may call, so PUT `/tests/{test_id}/stop` is not included unless you add it.
- **Credential handling:** Your Loader.io API key is stored once, encrypted, by your own Jentic One instance and injected as the loaderio-auth header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'run a load test' or 'get test results', and Jentic returns the matching Loader.io operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **BlazeMeter API** — Alternative cloud load testing platform with deeper protocol coverage
- **New Relic API** — Pair Loader.io's load generation with New Relic's APM during a test run

## FAQ

### Why is there no official OpenAPI spec for Loader.io API?

Loader.io does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Loader.io API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Loader.io API use?

The API requires an API key sent in the loaderio-auth request header. Through Jentic, the key sits in the vault and is injected at call time, so the agent never holds the raw value.

### Can I run a load test without verifying my domain?

No. Loader.io requires domain verification before traffic is sent. Use POST `/apps/{app_id}/verify` after registering the application; only then will tests created against that app run.

### What are the rate limits for the Loader.io API?

Rate limits are not stated in the spec. Loader.io enforces per-plan limits on concurrent users and total test minutes; these are tied to your subscription rather than the HTTP API.

### How do I run a load test from an agent through Jentic?

Search Jentic for 'run a load test against my application'. Jentic returns the PUT `/tests/{test_id}/run` operation. Load the schema, pass your test_id, and execute. Poll GET `/tests/{test_id}/results` to retrieve the run.

### How do I get the loader.io IPs for a firewall allowlist?

Call GET /servers. The response is the current list of loader.io egress IPs that you can add to your firewall or WAF rules so test traffic is not blocked.

### Can I limit what my agent is allowed to do with the Loader.io API?

Yes. Because the Loader.io API puts app and test ids in the URL path (for example `/apps/{app_id}/verify` and `/tests/{test_id}/run`), your self-hosted Jentic One instance lets you write rules that pin an agent to a single test, so it can run that test and read its results with GET `/tests/{test_id}/results` and nothing else. You decide which operations the agent may call, so a destructive action like PUT `/tests/{test_id}/stop` is not available unless you add it. Your rules also govern which stored credential is injected, so the agent never chooses its own scope.