What your API needs before we build a mobile app

An app built on an existing product needs three things:

• An API that supports the first-release tasks. The app must be able to read the right data and submit the required changes.
• Sign-in that works on a phone. Users need a secure way to start, refresh and end a session.
• A backend owner on your side. Someone must be able to explain the system and make or approve API changes.

If the API falls short, the project scope needs to account for the gaps. An app-facing layer can be discussed for that project. Its purpose is to support the app while keeping your existing product in place.

This article walks through what we ask before building on a client's system, and why each question matters. The same questions appear in shorter form on our mobile app development page.

Map the first-release tasks

API readiness depends on the tasks the app needs to support. Write down the three to five things a user must be able to do in the first release, then check each one against the API.

For example: check an account balance, approve a request or record a site visit. Each task needs a complete path through the data, permissions and response handling.

For each task, ask:

• Read: Can the app fetch the screen's data in a few requests, without downloading much more than it shows?
• Write: Can it submit the user's change and receive clear success and error responses?
• Permissions: Does the server check whether that user is allowed to make the change?

The usual gap is a task that the current web application performs through server-rendered pages or internal calls. The data exists, but there is no endpoint a mobile app can call.

Sign-in that works on a phone

Signing in to a mobile app works differently from a browser session. Before building, it helps to know:

• How users sign in today: email and password, a company identity provider, single sign-on or something else.
• Whether the backend issues tokens the app can store securely and refresh without asking the user to sign in again every time.
• How a session ends, and whether access can be revoked for a single device, for example when a phone is lost.
• Whether any sign-in step depends on a browser feature that needs a different flow on mobile.

If your organisation already uses an identity provider, the app should normally use it rather than introduce a second set of credentials.

Data access and permissions

Enforce permissions on the server. The app runs on a device controlled by its user. A modified client can inspect API responses and bypass checks that run only inside the app. OWASP's guidance on object-level authorisation explains why each API operation must check access to the requested record.

Check who can see each record and who can change it. The API must enforce those rules for each user, even if the web interface already hides restricted records.

It is also worth agreeing early which data the app may keep on the device, for how long, and what happens to it when the user signs out.

Who can change the backend?

Name the person who can change the backend. The app may need a missing field, a new filter or an endpoint shaped for a phone screen. Someone on your side must be able to explain the system and make or approve those changes.

In practice that means:

• A named person or team responsible for the backend, with time set aside for the project.
• Documentation or an API description that matches what is actually deployed.
• A test environment the app can use, with test accounts and data that is realistic but is not production customer data.
• An agreed way to request and release backend changes, so the app and the API move together.

Without this, even a well-designed app can end up waiting on questions nobody is able to answer.

Put the readiness questions in one place

The useful output of an API review is a short owner-and-action list, not a verdict that the API is simply "ready" or "not ready". This illustrative worksheet keeps product decisions separate from backend changes:

What if the API falls short?

Sometimes the gaps are larger than a few changes. The API may have been built for internal use, return data in a shape that does not suit a phone, or be difficult to change quickly.

There are two broad options:

• Extend the existing API. Your backend owner adds the capabilities the app needs.
• Agree an app-facing layer. Where extending the API is impractical, a separate layer may serve the app by calling your existing system.

The second option is scoped for the specific project. The proposal must define the layer's responsibilities, data access and owner. Your existing product stays in place.

A brand-new product with no existing system is a different case. There, what the app needs on the server side is agreed as part of the project scope.

An illustrative request and response

The app team needs examples that show the contract, including pagination and failure behaviour. The following uses synthetic identifiers and is only an illustration, not a proposed API specification:

GET /mobile/v1/work-orders?after=cursor_42&limit=2
Authorization: Bearer <test-token>

{
  "items": [
    {
      "id": "wo_demo_104",
      "status": "scheduled",
      "startsAt": "2026-10-05T08:00:00Z"
    }
  ],
  "nextCursor": "cursor_44"
}

A useful contract also says what an expired token, a missing record and a forbidden work order return. The app should be able to distinguish those cases through status codes and stable error identifiers, without parsing a human message. The same examples belong in the test environment so both teams can reproduce them before release.

A short checklist

Before asking for a proposal for an app on an existing product, try to answer:

1. Which tasks must the first release support, and does the API cover each of them?
2. How do users sign in, and can the backend issue and revoke tokens for each device?
3. Does the API enforce permissions for each user?
4. How are lists paginated, and which error codes can the app handle explicitly?
5. Which tasks work offline, what may stay on the device, and how are conflicts resolved?
6. Which server events should produce push notifications or refresh the app?
7. Who can explain and change the backend, and how are app and API changes released together?
8. Is there a test environment with test accounts, synthetic data and the same API version the app will use?

You can start with unanswered questions. Record them as unknowns so they can be checked before the scope and estimate are agreed.

For the wider brief, see what to send before asking for a mobile app proposal. For the choice of technology, see React Native for business apps.

Next step

If you are planning an app on top of an existing system, a short summary is enough to begin: what the app should do, what your API supports today and who looks after the backend. You can send it through the contact page. Please keep credentials and customer data out of the first message; they are not needed to discuss fit.