Designing a Laravel API for apps and admin panels

If the site, panel, and app each own their own rules, every price change is built three times and one copy is missed. The API is the shared contract. This KGSM delivery guide covers versioning, auth, docs, and rate limits from day one so the next app does not break the system.

This guide — Designing a Laravel API for apps and admin panels — is written from KGSM delivery work: scoped first versions, staged releases, and support after handoff.

Audience, risk, and how KGSM works

A product or technical lead who needs both a web panel and an app and fears duplicated logic and drifting data

Two databases mean prices, stock, and users drift within weeks and support never ends.

KGSM builds a versioned Laravel API so the panel, website, and app share one source, with staged delivery.

One source of truth for web and app

Stock, price, roles, and order status should be written once on the server. The app displays and captures data; do not put business decisions in the client where they are easy to bypass. The admin panel should use the same endpoints or the same domain services, not a separate query that later diverges from the app. At KGSM, version one of an API usually finishes auth, profile, one core resource such as orders or requests, and a filtered list. If the mobile team is ready earlier, a documented stub beats a temporary database on the phone. Design offline sync only when sellers truly work without coverage; otherwise the sync queue becomes the source of stock bugs. Give clients a server id and keep local ids only for pending uploads.

Keep price rules on the server even if the app works offline. A field-sales app on a separate database showed window prices three weeks behind the site.

Versioning, tokens, and roles

Put /api/v1 in place on day one even if you have a single client. When a field becomes required or changes meaning, introduce v2 and keep v1 alive until a forced app release. Keep access tokens short-lived, separate refresh, and make logout actually revoke. Check driver, customer, cashier, and admin roles on the server, not by hiding a button in the app. Rate-limit login and sensitive endpoints to slow password guessing. Request-id logs help the mobile team split network failures from server bugs. Open CORS only for panel domains; a wildcard in production lets any site drive the user’s browser at your API. HTTPS is mandatory; a token on HTTP is a key on the table. KGSM proves this before handoff with a real test client — Postman or a pilot app — not with an architecture slide.

A required address field without v2 broke the old app for every driver. Create a versioned v1 path on day one.

The frontend contract: docs, errors, pagination

The app team should not invent fields by guesswork. An endpoint list with sample requests and responses, error codes, and status meanings is part of delivery, not an extra. Validation errors should return field by field so the mobile form can translate them immediately. Paginate large lists from the start or the app will freeze on real data. Serve files through a short-lived URL or an access check, not a guessable public folder. If the web panel in React or Blade consumes the same API, a bug is fixed once. KGSM’s staged demos show the contract on one real panel page and one app list so mismatches appear early. Public look-and-feel can still move through web design if the catalog is read from the API, not from a parallel WordPress.

Logout must revoke the token, not only change the screen. A never-expiring token on a lost phone left panel access open.

The split-database mistake and how to repair it

Building the app on SQLite or a separate WordPress panel is a week-one shortcut and a month-three debt. Site price and app price diverge, stock goes negative, and customers fight support. If you already have two sources, pick a source of truth — usually Laravel — and make the other client a reader. Design two-way sync only with a queue and optimistic locking; otherwise last write wins and financial data dies. Force a staging test with a busy day’s real sales. Limit version one to a few key endpoints so mobile is not waiting on a full catalog. After handoff, keep one channel for API bugs; three teams will otherwise tell three stories. To freeze scope, tell contact which clients go live in the first ninety days so the estimate is not “every platform”.

An unpaginated product list on a weak line froze the app at login. Return validation errors field by field to the client.

An unpaginated list will freeze the app on real data. Frontend guessed a status field; cancel in the app did not match the panel.

Offline sync without locking created negative stock and two invoices for one basket. Do not leave a CORS wildcard in production.

A request id in logs halves mobile debugging time. A field-sales app on a separate database showed window prices three weeks behind the site.

A required address field without v2 broke the old app for every driver. Do not design two-way sync without optimistic locking.

Implementation checklist

• Keep price rules on the server even if the app works offline.
• Create a versioned v1 path on day one.
• Logout must revoke the token, not only change the screen.
• Return validation errors field by field to the client.
• An unpaginated list will freeze the app on real data.
• Do not leave a CORS wildcard in production.
• A request id in logs halves mobile debugging time.
• Do not design two-way sync without optimistic locking.

Field scenario 1

A field-sales app on a separate database showed window prices three weeks behind the site.

Keep price rules on the server even if the app works offline.

Field scenario 2

A required address field without v2 broke the old app for every driver.

Create a versioned v1 path on day one.

Field scenario 3

A never-expiring token on a lost phone left panel access open.

Logout must revoke the token, not only change the screen.

Field scenario 4

An unpaginated product list on a weak line froze the app at login.

Return validation errors field by field to the client.

Field scenario 5

Frontend guessed a status field; cancel in the app did not match the panel.

An unpaginated list will freeze the app on real data.

Field scenario 6

Offline sync without locking created negative stock and two invoices for one basket.

Do not leave a CORS wildcard in production.

Related KGSM pages

Continue with KGSM services: طراحی اپلیکیشن موبایل, برنامه‌نویسی و توسعه نرم‌افزار. Related reading: سفارش نرم‌افزار سازمانی — چطور تیم برنامه‌نویسی انتخاب کنیم؟, تکنولوژی‌های برنامه‌نویسی برای کسب‌وکار — Laravel، React و موبایل. For a scoped estimate, use the contact form.

When you apply this on a live team, write it as an operating rule, not a slide: Keep price rules on the server even if the app works offline. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Create a versioned v1 path on day one. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Logout must revoke the token, not only change the screen. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Return validation errors field by field to the client. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: An unpaginated list will freeze the app on real data. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Do not leave a CORS wildcard in production. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: A request id in logs halves mobile debugging time. Then assign an owner and a review date so the rule survives the first busy week.

When you apply this on a live team, write it as an operating rule, not a slide: Do not design two-way sync without optimistic locking. Then assign an owner and a review date so the rule survives the first busy week.