Picture a shopper who taps "Sign in" on your Android app, adds two items to the cart and lands on an empty checkout because the token refresh call quietly returned the wrong expiry. A scripted request against that refresh endpoint, fired on every build, would have caught the bad value before any phone ever saw it. That is the job API test automation does for mobile teams: it runs underneath your device-level UI tests, surfaces a broken backend within seconds, and seeds the accounts, carts and orders that each Android and iOS journey expects to find when it opens.
This guide walks through what belongs at each layer, four practical ways to pair API checks with mobile UI tests, how to set up a suite step by step, and a short comparison of the tools that handle each part of the job.
What does an API check see that a device run misses?
Every screen in your app reads from at least one endpoint. Your login screen waits on an auth service, your cart pulls totals from a pricing service, and order history fetches a paginated list one page at a time. An automated API check calls those same endpoints the way the app would, with a known payload, and then compares the response code, the headers and the exact JSON fields each screen parses against what that screen expects.
With no emulator to boot and no view hierarchy to render, a single check of this kind usually completes in well under a second. Teams can therefore afford hundreds of them per commit and keep slower device runs for the journeys a real person taps through. A useful way to split the work: the request asks whether the backend handed back the right cart total, and the device run asks whether a Pixel or an iPhone displayed that total and let the shopper pay.
Why do phones make backend checks harder to get right?
A single checkout screen on a phone may depend on a sign-in service, a payment provider and a feature flag at the same moment, and any of those three can blank the screen when its own team ships a change. Older app builds also stay installed on phones for months, so last spring's release may still send last spring's request shape to today's backend. Mobile networks drop and reconnect mid-request, and access tokens can expire while someone is halfway through checkout.
When mobile teams write their first API suite, the checks usually fall into four groups:
- Login, token issue and token refresh, including what happens when a token has expired.
- The three to five endpoints behind release-critical flows such as sign-up and payment.
- Error responses the app must render properly, such as 401 on a stale session or 404 on a deleted item.
- Compatibility calls that use request shapes from older app versions still in circulation.
If you are still sorting out which tool categories suit this work, our guide to API testing tools for mobile apps breaks down the main types.
Where should each mobile check run: request or device?
Device minutes are the scarce resource on most mobile projects, so the practical rule is to push a check down to a request whenever the request can prove the same thing, and spend real Android and iOS runs only on what a user has to see or touch. The table below sorts common mobile checks by the layer where a failure tells you the most.
Mobile checks sorted by request or device
| Check |
API layer |
Mobile UI layer |
Why |
| Business rules such as cart totals, coupon limits, plan eligibility |
Yes |
One smoke check |
The API can assert the exact figure; the screen only has to display it |
| Input validation and error codes (400, 401, 404, 500) |
Yes |
Confirm the app shows a readable message |
The server produces the error; the app has to cope with it gracefully |
| Login and token refresh |
Yes |
Run the login journey once per suite |
Forcing an expired token is simple through a request and awkward through taps |
| Data contract (field names and types each screen reads) |
Yes |
Not needed |
A renamed field can blank out every screen that parses it |
| Release-critical journeys like sign-up, login, checkout |
Setup and verification |
Yes, end to end on a device |
Users feel these directly, so they deserve a real device run |
| Layout, gestures, navigation, OS permission dialogs |
Not applicable |
Yes |
Only a rendered screen reveals these problems |
| Older app builds against the current backend |
Yes, replay old request shapes |
Optional on a device |
Previous releases stay on phones long after a new version ships |
The boundary between these layers is where integration testing for mobile apps earns its keep, and the patterns in the next section sit right on that boundary.
Four ways requests can shorten a device run
Once your request suite exists, the bigger payoff comes from wiring it into the phone tests themselves, so a checkout run on an iPhone no longer spends three minutes registering a user before it reaches the screen under test. Mabl's API testing page describes a similar split, with requests used ahead of a UI flow to prepare state and afterwards to read back what the backend saved. Here is how that plays out across four concrete Android and iOS situations.
1. Seed the account and cart with requests, then open the app at checkout
Rather than tapping through registration and adding items in every test, create the account and the cart with requests, then open the app at the step you actually care about. The UI test begins in a known state and skips several minutes of fragile navigation.
POST /test-users -> save userId, token
POST /carts {userId} -> save cartId
launch app as userId
open Cart, assert 2 items listed
2. Tap "Pay" on the phone, then ask the order service what it stored
After the tester's script taps "Pay", a request asks the backend whether the order really exists with status "paid". A green confirmation screen alone does not prove that the payment service recorded anything, so this pattern catches the case where the screen looks fine but the data is wrong.
3. Fail the build on a 500 before any emulator boots
Order your pipeline so the API suite runs before any device job begins. If the order service returns 500, the build fails in under a minute and nobody waits for a full device queue to discover the same fault through a spinner.
4. Delete test users and reset flags once the journey finishes
Delete the test user, cancel the order or reset feature flags with requests once the journey ends. Shared test environments stay tidy, and the next run does not trip over leftovers from the last one.
These patterns fit neatly alongside wider automated functional testing, where each check confirms a feature behaves as specified from the user's side.
How do you set up API test automation?
A first useful suite rarely needs more than a few dozen requests. Six steps cover most mobile projects:
- Pick the endpoints that matter. Start with the calls behind login, payment and the journeys you would block a release for.
- Define environments and test data. Keep base URLs per environment, and decide which values stay fixed (a seeded product ID) and which must be generated per run (an email address) to avoid two runs colliding.
- Write assertions beyond the status code. Check headers and the specific body fields each screen reads, along with their types.
- Chain requests with variables. Extract a token or an order ID from one response and feed it into the next call, the same way the app does.
- Run the suite in CI on every build. Treat a failed API check like a failed compile. Our walkthrough on building a CI/CD pipeline for mobile app testing shows where this stage fits.
- Report and triage. Store request, response and timing for each failure so the person on call can tell a backend fault from a test data problem quickly.
If your services follow REST conventions and you want depth on that style specifically, see our piece on automating REST API tests.
Which tool fits where your mobile API checks need to run?
Your choice mostly comes down to placement: a standalone request suite in CI, requests living beside browser tests, or requests called from inside an Android or iOS test case. The table below sorts the options by what each vendor's own documentation says they do on each layer, in three loose groups with no ranking implied.
Request checks versus phone runs, product by product
| Product |
Role in a mobile stack |
Request checks |
Device UI runs |
Requests and taps in one case |
| Postman |
API platform with the Postman CLI for running collections in CI |
Yes |
No |
No, pair it with a UI tool |
| REST Assured |
Open-source Java library for testing REST services |
Yes |
No |
Only through your own Java code, for example alongside Appium |
| Karate |
Open-source framework covering API, mocks, performance and browser UI |
Yes |
No |
API plus browser UI |
| Playwright |
Open-source web testing library that ships an APIRequestContext for HTTP calls |
Yes |
No, mobile viewports are emulated in a desktop browser |
Requests plus web pages |
| Testsigma |
Test automation platform |
Yes, via a REST API step |
Yes |
Yes, a REST API step inside a web or mobile test case |
| ACCELQ |
Codeless automation platform |
Yes, including REST, SOAP, Kafka and message queues |
Yes, iOS and Android |
Unified web, API and mobile platform |
| mabl |
Test automation platform |
Yes, and it imports Postman collections |
Yes, iOS and Android |
Yes, API calls chained into web and mobile flows |
| QApilot |
Mobile testing platform with API automation |
Yes, through HTTP Master collections |
Yes, Android and iOS |
Yes, an HTTP Source step inside a mobile test case |
| Appium |
Open-source UI automation |
Uses your language's HTTP client |
Yes |
Only within your own test code |
| Maestro |
Open-source mobile UI flow framework |
Not an API tool, though flows can make HTTP calls |
Yes |
Setup and backend checks inside flows |
| Mobile Next (mobile-mcp) |
MCP server that lets agents drive iOS and Android apps |
No |
Agent-driven device control |
No |
Here is what each one documents, with a source link for every entry:
- Postman is a mature API platform, and its CLI runs collections from a terminal or a pipeline.
- REST Assured gives Java teams a fluent way to validate services, and it can share a codebase with Appium tests.
- Karate combines API tests, mocks and performance runs in one open-source framework, with UI automation aimed at browsers.
- Playwright gives web teams an APIRequestContext for HTTP calls beside page actions, though its mobile support stops at emulated viewports rather than native Android or iOS apps.
- Testsigma documents a REST API step that can sit next to UI steps in a mobile test case.
- ACCELQ markets codeless API automation across many protocols alongside real-device mobile testing.
- mabl runs imported Postman collections in CI and chains API calls into end-to-end flows.
- QApilot runs API collections and lets a mobile test case call an API mid-run, covered in the next section.
- Appium focuses on UI automation across platforms; API calls come from whatever HTTP library your test language uses.
- Maestro includes a JavaScript HTTP client so flows can seed data or check backend state. See our Maestro testing guide for more.
- Mobile Next gives AI agents structured control of native apps and devices, with no API testing features documented.
For a structured selection process, read our guide to choosing an API automation testing tool for mobile apps, or browse a wider list of automated software testing tools.
How does QApilot run API tests next to mobile UI tests?
QApilot is a mobile testing platform that also runs API tests, so the four request-plus-device setups described earlier, from seeding a cart to deleting test users, can sit inside one Android or iOS test case instead of being split across two tools.
HTTP Master collections. HTTP Master organizes requests into collections and modules. You can build calls by hand or import an OpenAPI (Swagger) spec. Requests support GET, POST, PUT and DELETE, Basic or Bearer token auth, custom headers, and form-data or raw bodies in JSON, XML or plain text. Pre-request and post-response scripts handle preparation and follow-up logic. Variables pull values from responses by path, with assertions such as Equal To, Contains and greater or less than comparisons. Running a collection lets you choose test data, set a delay between requests and save responses, and the report lists each request with response times, assertion results and failures.
API calls inside a mobile test case. An HTTP Source step calls an API during execution and stores the response, so a value such as an order ID can drive later UI steps in the same run. In practice that covers seeding the checkout data and reading back the stored order without bringing in a second framework.
Test data that avoids collisions. Static and dynamic test data items can be bound to requests, and random test data for APIs (alphanumeric, numeric, regex based or picked from your own list) is generated just before execution. Values that scripts update can be saved back to static test data.
The mobile side. Tests are recorded and played back on Android and iOS, locally or on supported cloud devices. Cross-platform test cases hold platform-specific steps where needed, test plans group runs and produce reports, and CI/CD is enabled from test plans, so an HTTP Source step runs wherever its test case runs. AI auto-healing applies to UI locators, with a person approving each healed step; read more on self-healing test automation. QApilot also works alongside your existing device cloud through the BrowserStack and Sauce Labs integrations.
Full configuration details are in the QApilot API test automation docs.
What mistakes should you avoid?
- Pushing every check through the UI. Coupon limits and cart totals verified by tapping through screens take minutes and fail with vague errors, so assert those figures with a request instead.
- Sharing one hard-coded test user. When four emulators log in as one seeded account, their carts overwrite each other mid-run. Generate a fresh user and cart for every parallel run instead.
- Asserting only on a 200 status. A 200 response that silently drops the
price field still leaves the cart screen showing a blank total on every phone.
- Ignoring older app builds. Replay request shapes from previous releases so a backend change does not break phones that have not updated.
- Running API checks after the device suite. Schedule the request suite ahead of the device queue so a backend fault fails the build within a minute, then keep your regression testing suite focused on journeys.
Related reading
