API Stress Testing
APIs usually fail under load before they fail under attack — on launch day, during a campaign, or when a client integration ramps up. We push your APIs to their limits under controlled conditions and show you exactly where, and how gracefully, they break. Every run also grades your API's HTTP security headers, so the performance evidence comes with a security dividend.
Who this is for
- You are preparing for a launch or major release and need to know the API will hold
- You expect seasonal or campaign traffic peaks well above your day-to-day load
- You give customers SLAs and need evidence of the capacity behind them
- You have had a denial-of-service near-miss and want to plan resilience properly
What we test
Coverage runs in depth, not breadth alone — each stage goes past where the one above it stops.
- Baseline
Normal-load behaviour
What the API does when nothing is wrong — the reference every later number is judged against, measured with realistic think time rather than an artificial flood.
- Ramp
Where degradation starts
Concurrency scaled toward 1,000+ virtual users with controlled ramp rates, to find the point performance begins to bend rather than the point it snaps.
- Soak
What only time reveals
Sustained load over a long run, which is where memory leaks, connection-pool exhaustion and slow resource drain appear — none of them visible in a short test.
- Spike
Sudden arrival
Launch-day and campaign traffic patterns: whether the platform absorbs a step change or falls over, and how it behaves on the way back down.
- Breakpoint
The failure mode itself
Where it actually breaks, and how — measured at P50 through P99 with throughput and error-rate correlation, because an average hides every failure worth knowing about.
- Security
What the load exposes
Fifteen response headers captured and graded A-F with values validated rather than merely present, plus absent rate limiting and error responses that leak internal detail under stress.
What the testing looks like
Our own tooling and the report it produces — here is what you actually receive.
The tooling
The report you receive
Screenshots show synthetic demo data.
What you get
The package in three parts — what you read, what you act on, and what happens after.
What you read
A grade for the board, the percentiles for the engineers.
- Executive summary with an overall performance grade written for non-technical stakeholders
- Full metrics and percentile breakdown per endpoint across every test type run
- A graded security-header section in the same report, with per-header assessment and severity
What you act on
Ordered by impact, with the conditions to reproduce.
- Error analysis with the load conditions needed to reproduce each failure mode
- Prioritised capacity and configuration recommendations, ordered by impact
How it runs
How a simulation runs
Scoping & Rules of Engagement
Which hosts, people or systems are in play, at what intensity, in what window — plus your point of contact, the escalation route, and who holds the authority to stop it.
Reconnaissance & Scenario Build
Building the thing that will actually run: a pretext assembled from your own public footprint, an agent and scope for a ransomware run, or a load suite from your API collection.
Written Authorisation
Nothing executes until it is signed. Where a simulation touches your people or your availability, that authorisation is a separate document from the standard engagement terms.
Controlled Execution
The exercise runs inside the agreed window, watched by a named engineer, with the means to halt and reverse it immediately if you ask or if anyone becomes distressed.
Detection & Response Measurement
What your tooling saw, what your people did, and how long each took. This is the output that matters — the simulation itself is only the instrument for producing it.
Stand-down & Reporting
Everything is reversed and removed: files restored, assets deleted, campaigns closed, with the restoration reconciled. Then the annotated timeline, the findings and what to change.
This is our simulation sequence. The six-phase methodology CREST assessed governs our penetration testing, which is a different service.
Prerequisites
- An agreed test window and target environment — non-production recommended; production only by explicit written agreement
- An API specification or Postman collection covering the endpoints in scope
- Valid credentials or keys where protected endpoints are in scope
- A signed Laneden authorisation form
Frequently asked questions
Will this take my API down?
Finding the point where it would is the point — safely. We agree the window and environment up front, ramp load progressively rather than flooding, and set stop conditions before testing starts, so limits are found under control rather than discovered in production.
Does this replace an API penetration test?
No. The security layer here is HTTP response-header analysis plus what load surfaces — missing rate limiting, error detail leaking under stress. A penetration test goes much further: an engineer manually attacking authorisation, business logic and data handling. They cover different ground and pair well — many clients run this alongside our API Penetration Testing service on the same API.
What does the security-header analysis check?
Every run captures fifteen HTTP security headers from your API's responses and produces a weighted A-F grade. We validate values, not just presence — an HSTS header with an inadequate max-age is flagged even though the header exists — and rate each header's relevance separately for API and web contexts, so you are not penalised for headers that only matter in a browser. Deprecated headers such as X-XSS-Protection are flagged and excluded from scoring.
What do you need from us?
A Postman collection or API specification for the endpoints in scope, credentials for any protected endpoints, and an agreed test window and environment. From there we handle the test design and execution.
How much load can you generate?
Load is scaled to the engagement: from gentle baselines that characterise normal behaviour up to 1,000+ concurrent virtual users for spike and stress runs. We agree the ceiling with you before testing begins.
Related services
API Testing
APIs move your most sensitive data, yet they rarely get the scrutiny given to the interfaces built on top of them.
Learn more →
Web Application Testing
Your web applications are your most exposed attack surface.
Learn more →
External Infrastructure Testing
Everything you expose to the internet — mail, VPN, remote access, forgotten subdomains — is being probed constantly by people who never asked permission.
Learn more →
Ready to test your defences?
Tell us about your API stress testing requirement — we'll come back with a scoped proposal within two working days.
Free remediation retesting* to confirm your fixes (subject to assessment size).