Last updated: October 2026 · REST APIs, Sanctum and integrations
A mobile app is only as good as the API behind it. When the API is vague, the app team guesses, the guesses diverge, and three months later you are paying to fix both. I'm Arun Tyagi, a Laravel API developer based in Sector 58, Noida, and I build the kind of backend that the frontend team does not complain about.
That means consistent response shapes, predictable errors, proper versioning and documentation that matches reality. It also means thinking about authentication, rate limits and webhooks before they become incidents.
Planning an API?
Send screens, a rough endpoint list or the existing code. I will give you a view in one call.
What a good API build includes
- Authentication. Sanctum tokens for mobile and SPAs, with device naming and revocation.
- Resources and validation. API resources for stable output, form requests for strict input.
- Versioning.
/api/v1from day one, so you can change things without breaking old app builds. - Pagination and filtering. Cursor or page-based, with sensible defaults and caps.
- Rate limiting. Per user and per IP, tuned to your traffic.
- Webhooks and queues. Payment gateways and third-party callbacks handled idempotently.
- Documentation. OpenAPI or Postman collection, kept current.
A small example
A typical protected route looks like this:
Route::middleware('auth:sanctum')
->prefix('v1')
->group(function () {
Route::apiResource('orders', OrderController::class);
});Short, readable, and testable. The real work sits in policies, resources and the queries behind them.
Typical API projects
- Backend for a delivery or booking app with Android and iOS clients.
- Payment and subscription API with Razorpay or Stripe webhooks, as in the PayBev project.
- Partner or dealer API that lets other systems push orders into yours.
- Headless backend for a React or Next.js storefront.
- Integration layer between ERP, accounting and your web app.
Pricing
| Scope | INR range | Includes |
|---|---|---|
| Small API, up to ~15 endpoints | ?40,000–?70,000 | Auth, CRUD, docs, tests |
| Mid-size mobile backend | ?70,000–?1,20,000 | Roles, payments, notifications |
| API inside a SaaS product | Part of ?1,20,000–?4,50,000 | Tenancy, billing, admin |
| API audit | ?3,000 per hour | Security, performance, contract review |
Common mistakes I fix
- Returning raw Eloquent models, which leaks fields and breaks when the schema changes.
- No pagination on list endpoints, so one big customer takes the server down.
- Error responses that differ by endpoint, forcing the app to special-case everything.
- Webhook handlers that process the same event twice and double-charge or double-credit.
How I keep API and app teams in sync
Before writing code I agree an endpoint contract with the mobile or frontend team: paths, request bodies, response shapes and error codes. I then deploy stub responses to staging so they can start immediately. When real logic replaces the stubs, nothing changes on their side. This one habit removes most of the integration arguments I see on projects that start with "we'll sort the API out as we go".
FAQ
Sanctum or Passport?
Sanctum for almost everything: first-party apps and SPAs. Passport only if you need full OAuth2 for third parties.
REST or GraphQL?
REST by default. GraphQL when many clients need very different shapes of the same data.
Can you work with our mobile team?
Yes. I share a contract first, mock responses early and keep a staging API available for them.
Related
If the API is part of a product with tenants and subscriptions, read Laravel SaaS development. For general services, Laravel development. To hire, see hire a Laravel developer.
Next step: WhatsApp your endpoint list or book a call.