The three questions inside API performance testing
| Capacity | How much concurrent traffic before latency degrades. Needs a load generator. Run before releases and after architecture changes. |
| Regression | Did this pull request make a call slower than it was. Needs a baseline and comparison, not high concurrency. |
| Correctness | Is the response right, including under awkward input. Needs assertions on bodies. Cheapest of the three and the one most often skipped. |
Why regression is the one worth automating first
Capacity testing is expensive to run and rarely changes between releases. Performance regression is the opposite: it happens gradually, one pull request at a time, and by the time a capacity test catches it you are looking at six months of accumulated changes and no idea which one did it.
A simple per-call timing comparison against a baseline, run on every change, catches the ten-times-slower query on the day it lands. That is worth more than a quarterly capacity report.
The correctness floor
None of the timing numbers mean anything if the responses are wrong. An endpoint that returns an empty array is extremely fast. This sounds obvious and is exactly how a service ships with a broken filter and excellent latency graphs.
So the order is correctness, then regression, then capacity. Most teams do them in reverse because capacity testing is the one that looks like performance work.
What generated coverage contributes
API test plans include boundary and stress-shaped cases, which surface the input combinations that make an endpoint slow for a structural reason rather than a load reason. A query that degrades with a large page size will show up here long before a capacity test finds it.
That is not load testing and it is not a replacement for one. It is the cheap layer underneath.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
If you would rather not install anything, the dashboard does the same thing. Everything else the command line can do is in the CLI repository.
Session, state, ordering and cleanup are covered in the API testing documentation.
Where the regression usually is
When an endpoint gets slower between releases, the cause is nearly always one of three things, and knowing them shortens the search considerably.
A query that lost its index, or gained a condition the index does not cover. This is the most common by a distance and it produces a change that is invisible in the diff because the SQL looks fine.
A call that used to be one round trip and is now several, usually because a helper started fetching related records individually inside a loop. The code reads better than it did before, which is how it passes review.
Something that grew. A response that includes a collection which used to have five entries and now has five hundred, because the product succeeded. Nothing broke, and the endpoint is now slow for everybody.
Cadence
Two routes, and the choice is really about who owns the pipeline. Connecting the GitHub App from the dashboard needs no change to your repository at all, because it reacts to the deployment your build already emits. Adding a GitHub Actions step puts the check in the repo where it gets reviewed like the rest of the build.
What TestSprite covers of the three
The third one, correctness, and the boundary cases that surface structural slowness. A query that degrades with a large page size shows up as a failing or slow boundary case long before a capacity test reaches it, and at a fraction of the cost.
Coverage comes from API Discovery plus your specification, with plans spanning functional, schema, authorization, error-handling and boundary categories. Auto-Authentication keeps sessions alive across a run, Dynamic Variables carry values between calls, Dependency Chains derive execution order from what each case needs and produces, and Auto-Cleanup removes exactly what the run created.
What you get is the layer most performance programs are missing: something running on every pull request that would notice an endpoint returning empty results, which is the failure a throughput graph reports as excellent.
Does TestSprite measure latency?
It verifies correctness rather than capacity. Timing and throughput under sustained concurrency need a dedicated performance tool.
What is a reasonable baseline?
Your own previous numbers on the same environment. Absolute targets borrowed from other products tell you very little.
Should performance tests block a merge?
A large regression on a critical path, yes. Small variation, no, or you will spend your time tuning thresholds instead of shipping.
Why do our numbers vary so much?
Usually a shared environment, a cold cache or different data volume. Control those before you trust any comparison.
Can one tool do all three?
Some claim to. In practice the capacity question needs a load generator and the correctness question needs assertions on bodies, and doing both well in one run is rarer than the marketing suggests.
Correctness, then regression, then capacity.
API performance testing is three questions with three answers. Regression is the one worth automating on every change, correctness is the floor beneath all of it, and capacity is the expensive one most teams start with.