One Laravel API, web and mobile: how we structure it

Our UK garage-booking SaaS has this shape: a Laravel API, a Next.js web application for garages and customers, and React Native apps for iOS and Android. Car owners pick a slot, pay and receive invoices and reminders on their phone. Garages manage services, slots and customers. It took about a year as one product, and it is multi-tenant, since many garages subscribe. Code samples here are illustrative rather than taken from that project.

The test is simple. If a rule would have to be written twice, once in TypeScript for web and once for mobile, it belongs in the API. Client-side validation is a courtesy. A phone can be running an old build, and anyone can call your API directly.

The browser and the phone are different security environments. Laravel’s Sanctum covers both: cookie-based sessions for a first-party web front end, and API tokens for mobile apps.

// Mobile login: one named token per device
$token = $user->createToken($request->device_name, ['bookings:write']);

return ['token' => $token->plainTextToken];

Naming a token per device gives users a “signed-in devices” list and lets you revoke a lost phone. Store the token in the device’s secure storage, not in plain async storage. Remember that a Next.js server calling the API on a user’s behalf is a third case, and it should forward that user’s identity rather than use an all-powerful service key.

The website updates for everyone when you deploy, and phones don’t. Some users will run an old build for months, so an API change that is safe for your web app can break them. Three habits help:

• Add, don’t change. New fields are safe. Renamed fields and tightened validation aren’t.
• Version the routes, such as /api/v1, and only introduce v2 when you must. Each version is code you have to keep.
• Include a minimum version check. The app sends its build number, and the API can answer “please update”. Build this into your first release. It can’t be added to versions already installed.

The same API has to be pleasant on poor mobile signal. Use API resources so responses contain what a screen needs and no more. Use cursor pagination for long lists, so new records don’t shift pages as people scroll. Make payment and booking requests idempotent, using a client-generated key, because a phone that loses signal will retry, and you don’t want two bookings. Send a notification for slow results, rather than keeping a phone waiting on a held request.

With many garages on one platform, every query must belong to a tenant. Put this in a global scope or base query, so a forgotten clause doesn’t expose someone else’s customers, then write a test that tries it. A car owner may also use more than one garage, so decide early whether accounts belong to a garage or to the platform. That decision is hard to change later and affects login, data ownership and what you say about privacy.

With separate clients, the API is a contract between teams. Laravel feature tests can pin response shapes, and a shared OpenAPI description lets the Next.js and React Native code generate types from one source. When someone changes a response, the failure then appears in CI and not in an app store review. This structure also means the mobile route can change later, as we discuss in wrapped web app or React Native.