Your app doesn't do much on its own. It fetches restaurant lists from an API. It sends login credentials to an API. It pushes payment details to an API and waits for a confirmation. If any of those API calls fail, break, slow down, or return garbage data, user sees a blank screen, an infinite spinner, or a cryptic error message. They don't know API broke. They think your app broke.
API testing exists to catch those failures before your users do. And unlike UI testing, where you're fighting with selectors, device specific rendering, and flaky wait times, API testing is deterministic. You send a request, you get a response. The response either matches what contract says or it doesn't. No ambiguity.
That clarity makes API tests faster to write, faster to run, and more stable than UI tests. A team that invests in API testing catches 60-70% of backend bugs before they reach UI, which means fewer flaky test failures, fewer last-minute sprint fires, and fewer "works on my machine" conversations.
Here's how to think about it.
The 5 types of API tests that actually matter
There are dozens of ways to categorize API tests. Most of those categories exist in textbooks and conference talks, not in real sprint backlogs. These five are ones teams actually run.
Contract testing
Does API return what it promised? Contract testing validates response shape: correct status codes, correct field names, correct data types, correct required fields present. If /users endpoint is supposed to return { "id": int, "name": string, "email": string }, contract testing confirms it does. Every time.
This sounds basic. It's also test type that catches most regressions. A backend developer renames email to emailAddress in a refactor. The API still works, still returns 200, still has data in every field. But every mobile client that reads response.email now gets null. The app shows a blank email field or crashes. Contract testing catches this in CI before rename ever reaches staging.
Tools: Postman (schema validation), Pact (consumer-driven contracts), Dredd (API Blueprint validation), or just a JSON schema check in your test runner.
Functional testing
Does API do right thing? Functional testing goes beyond shape and checks behavior. Create a user via POST, then fetch that user via GET. Does GET return user you just created? Update user's name via PUT. Does GET now return new name? Delete user via DELETE. Does GET now return 404?
This is CRUD testing, and it's bread and butter of API test suites. You're not checking if response has right fields (that's contract). You're checking if API actually performs operation correctly.
The key to functional API tests: each test should be independent. Test A creates a user, tests user, and deletes user. Test B does same with a different user. They don't share data. They don't depend on execution order. If Test A fails, Test B still runs. This is same test data isolation principle that applies to UI tests, and it's just as easy to violate.
Negative testing
Does API fail correctly? Send a login request with no password. Send a payment request with a negative amount. Send a string where an integer is expected. Hit an endpoint that doesn't exist. Send a request with an expired auth token.
The API should return right error code (400 for bad input, 401 for unauthorized, 404 for not found, 422 for validation failures) with a useful error message. "Invalid request" is useless. "Password field is required" is useful.
Negative testing is where security bugs live. If sending {"amount": -50} to payment endpoint results in a refund instead of an error, that's a security vulnerability, not just a bug. If sending ' OR 1=1 -- in username field returns all users, that's SQL injection. If sending a 10 MB payload crashes server, that's a denial-of-service vector.
Most teams skip negative testing because it feels like edge-case hunting. It's not. It's safety net between your API and internet.
Performance testing
Does API stay fast under load? A login endpoint that responds in 100ms for one user might respond in 4 seconds when 500 users hit it simultaneously during a flash sale. Performance testing measures response time under increasing load to find point where things degrade.
Three numbers matter:
P50 (median response time). Half your requests are faster than this, half are slower. This is your typical user experience.
P95 (95th percentile). 5% of your requests are slower than this. This is your worst-case for most users.
P99 (99th percentile). 1% of your requests are slower than this. This catches outliers that hit users on slow connections or during garbage collection pauses.
If your P50 is 150ms but your P95 is 3 seconds, you have a long-tail latency problem. Most users are fine. 5% are having a terrible experience. The median hides problem.
Tools: k6 (JavaScript-based, open-source, runs in CI), Gatling (Scala-based, good reporting), JMeter (Java, widely used, ugly but functional), Locust (Python-based, simple to script).
Authentication and authorization testing
Does API protect what it should? Auth testing checks two things:
Authentication: Can a user without valid credentials access API? Send requests with no token, expired tokens, malformed tokens, tokens from a different environment (staging token against production). Every request should return 401.
Authorization: Can a user access resources they shouldn't? User A requests User B's profile. A regular user requests an admin endpoint. A free-tier user requests a premium feature. Every request should return 403.
Auth bugs are bugs that make news. If User A can read User B's messages by changing user ID in URL (an IDOR vulnerability), that's a data breach. Auth testing catches these before they ship.
How to organize API tests in your pipeline
Not every test type runs at same stage.
On every PR (seconds to minutes): Contract tests and core functional tests. These are fast (no external dependencies, no load simulation) and catch most common regressions (field renames, broken CRUD operations, incorrect error codes). Run them in CI. Block merge if they fail.
Nightly (minutes): Negative tests, extended functional tests, auth tests. These take longer because they cover more scenarios and edge cases. Run them against a staging environment after day's PRs are merged.
Before release (minutes to hours): Performance tests. Simulate expected peak load against staging environment. Check that P50, P95, and P99 are within your targets. If login endpoint's P95 jumped from 300ms to 2 seconds since last release, investigate before shipping.
Continuously (production): Monitor real API response times, error rates, and availability using APM tools. When production metrics cross a threshold (error rate above 1%, P95 above 2 seconds), alert on-call engineer.
This layering matches same pipeline structure used for mobile CI/CD: fast tests gate PR, slower tests run nightly, heaviest tests run pre-release.
Where mobile teams get stuck with API testing
Most API testing guides are written for backend teams. Mobile teams have a different set of problems.
The API changes without warning. The backend team ships a breaking change (renamed field, removed endpoint, changed auth flow) without notifying mobile team. The app breaks in production because mobile release was built against old API contract. Consumer-driven contract testing (using Pact or a similar tool) prevents this: mobile team defines contract it expects, backend CI runs against that contract, and build fails if contract is violated.
Staging API doesn't match production. The staging API has test data, different rate limits, and sometimes different behavior than production. API tests pass on staging, then mobile app breaks on production because production API handles edge cases differently. The fix: run a subset of non-destructive API tests (health checks, read-only endpoints, auth validation) against production on every release.
Error responses are inconsistent. One endpoint returns {"error": "Not found"} for a 404. Another returns {"message": "Resource does not exist", "code": 404}. A third returns an HTML error page because API gateway caught error before it reached app server. The mobile app has to handle all three formats. Test actual error responses, not just status codes.
Timeouts aren't tested. The mobile app has a 10-second timeout on API calls. The API usually responds in 200ms. But under load, checkout endpoint sometimes takes 12 seconds. The app shows a "Something went wrong" error, but payment actually went through. The user taps "Pay" again. Double charge. Test what happens when API responds after mobile app's timeout window. This is single most common API-related production bug in mobile apps.
Rate limiting surprises. The API has a rate limit of 100 requests per minute. The mobile app makes 5 API calls per screen load. A user rapidly switching between screens can hit rate limit and start getting 429 (Too Many Requests) responses. Test your app's behavior when it receives a 429. Does it back off and retry? Does it show an error? Does it crash?
Postman as starting point
If your team isn't doing API testing yet, start with Postman. Create a collection with core API endpoints. Add a few test assertions to each request:
// Contract: check status and shape
pm.test("Status is 200", () => pm.response.to.have.status(200));
pm.test("Has user ID", () => {
const json = pm.response.json();
pm.expect(json.id).to.be.a("number");
pm.expect(json.email).to.be.a("string");
});
Run collection manually first. Then export it and run it in CI using Newman (Postman's CLI runner):
newman run my-collection.json --environment staging.jsonThat's a working API test suite in an afternoon. It's not comprehensive, but it catches field renames, broken endpoints, and auth failures that cause most mobile app crashes. You can build from there.
FAQ
What is an API testing strategy?
A documented plan for how you verify your APIs work correctly. It defines which test types you run (contract, functional, negative, performance, auth), when they run (PR, nightly, pre-release), and what tools you use.
Which API tests should I automate first?
Contract tests and core CRUD functional tests. They're fast, stable, deterministic, and catch most common regressions (renamed fields, broken endpoints, wrong status codes). Start there and expand to negative and performance testing later.
What tools are used for API testing?
Postman (manual + automated via Newman), k6 (performance), Pact (contract testing), REST Assured (Java), Supertest (Node.js), pytest + requests (Python). For monitoring production APIs: Datadog, New Relic, or any APM tool.
How is API testing different from UI testing?
API tests send HTTP requests and check responses. No browser, no device, no selectors. They're faster (milliseconds vs seconds per test), more stable (no flakiness from UI rendering), and catch backend bugs earlier. UI testing validates full user experience. API testing validates data and logic layer underneath.
What's most common mobile API bug?
Timeout mismatches. The app has a 10-second timeout. The API usually responds in 200ms but takes 12 seconds under load. The app shows an error, but backend actually processed request. The user retries. Double charge, double submission, or duplicate records.
How often should API tests run?
Contract and functional tests on every PR (fast, blocks merge). Negative and auth tests nightly. Performance tests before each release. Production monitoring continuously.
