Loader.io API
Agent-ready OpenAPI document · curated by JenticDeveloper ToolsTesting QaapiKey13 EndpointsREST
Know of an official OpenAPI document? Contribute it →
For Agents
Register applications, verify test domains, run cloud-based load tests, and retrieve performance results from the Loader.io API.
Use for: I need to run a load test against my staging environment, Verify my domain so loader.io can hit it, List all tests I have configured for this app, Get the latest results for a load test I just ran
Not supported: Does not handle application performance monitoring, error tracking, or synthetic transaction monitoring - use for cloud load test orchestration only.
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.
Install Jentic One Beta
Connect the Loader.io API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Loader.io API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Floader.io%2Floader-io" | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Floader.io%2Floader-io" | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Loader.io API.
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
Patterns agents use Loader.io API for, with concrete tasks.
★ 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.
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.
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.
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
13 endpoints — jentic publishes the only available openapi specification for loader.
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
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
Why Jentic?
What agents get from Jentic-routed access to this vendor.
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 isolation
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.
Intent-based discovery
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
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Loader.io API through Jentic.
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.
GET STARTED