Laravel APIs

Laravel API development for apps and partners that depend on it

We design and build JSON APIs with API resources, Sanctum or Passport, form request validation and an OpenAPI document, so the teams consuming it can work without guessing.

  • OpenAPI docs with every release
  • Feature tests per endpoint
  • Revocable per-device tokens
What is included
  • API resources
  • Versioning
  • Sanctum and Passport
  • Rate limiting
  • Validation with form requests
  • OpenAPI documentation
Get a free quote Reply within one business day. NDA on request.
The problem

API problems that bring teams to us

An API is a promise to code you do not control. A mobile app installed last year, a partner's integration, a front end built by another team: all of them break if a field is renamed or an error comes back in a new shape. Most API problems we are called in to fix are broken promises of that kind, plus tokens that never expire and endpoints that return an entire table.

We build APIs on Laravel for companies launching a mobile app, splitting a front end from its back end, or opening their platform to customers and partners. The framework supplies good parts for the job. Our contribution is the contract: consistent resource shapes, clear versioning, authentication matched to who is calling, limits that protect the server, and documentation generated from the same code that serves the requests.

  • Responses change shape without warning

    Controllers return models directly, so a new database column appears in the JSON and a renamed one disappears. The mobile team learns about it from crash reports.

  • Old app versions cannot be forced to update

    Users on last year's build still call last year's endpoints. Without versioning, every server change is a gamble on which installed apps will stop working.

  • Authentication was bolted on

    One long-lived token per user, stored in plain text, with no scopes and no way to revoke a single device. A lost phone means resetting everything.

  • No documentation anyone trusts

    There is a Postman collection from two years ago. Front-end developers read controller code or ask in chat to learn which fields an endpoint accepts.

What we do

What a well-built Laravel API includes

Each API we deliver is treated as a product with its own contract, tests and documentation, whoever the consumer is.

API resources

Eloquent API resource classes define exactly which fields leave the server, with conditional relationships, consistent pagination metadata and one error format across every endpoint.

Versioning

Route groups and resource classes per version, a deprecation policy announced in response headers, and usage logging that shows when an old version can finally be retired.

Sanctum and Passport

Sanctum personal access tokens with abilities for first-party apps and cookie-based sessions for SPAs. Passport when third parties need a full OAuth2 authorization flow.

Rate limiting

Named rate limiters per user, token or plan, stricter limits on login and password endpoints, and clear retry headers so clients can back off politely.

Validation with form requests

Every write endpoint has a form request class holding its rules and authorization check, returning field-level errors in a predictable structure.

OpenAPI documentation

A specification generated from routes, form requests and resources, published as browsable docs with example requests, and checked in CI against real responses.

Typical projects

APIs we typically deliver

01

Server side for a mobile app

Authentication, profile, content, payment and push notification endpoints for iOS and Android clients, with versioning planned for app releases that stay installed for years.

02

API for a separate SPA

A React or Vue front end on its own subdomain talking to Laravel through Sanctum cookie authentication, with CORS and CSRF configured correctly from the start.

03

Public or partner API

Scoped credentials for each partner, per-client rate limits, webhooks for the events they care about and a developer portal built from the OpenAPI document.

04

API layer over an existing application

Endpoints added to a running Laravel application by reusing its models, policies and actions, so web and API behavior cannot drift apart.

In depth

Design choices inside a Laravel API

Resources are the contract

We never return an Eloquent model straight from a controller. Each response goes through an API resource class that lists its fields one by one. That gives a single file to review when the contract changes, keeps internal columns private by default, and lets us load relationships only when the client asks for them. Lists are paginated, with cursor pagination where the data set is large or changes quickly. Errors follow one structure, with a machine-readable code beside the human message, so client developers write their error handling once.

Choosing between Sanctum and Passport

The question is who is calling. For your own mobile app, Sanctum issues personal access tokens, one per device, each with a list of abilities and each revocable on its own. For your own SPA on a related domain, Sanctum uses the normal session cookie, which keeps tokens out of browser storage. Passport is the choice when outside developers build on your platform and users must grant them access, because that needs real OAuth2 flows with client credentials, authorization codes and refresh tokens. Running Passport where Sanctum would do adds moving parts you then have to maintain.

Versioning you can live with

We version in the URL path because it is visible in logs and easy for client developers to reason about. A new version is created only for breaking changes. Adding a field is not one. Removing or renaming a field is. Older versions keep their own resource classes over the same underlying actions, so a bug fix in business logic reaches every version at once. We log which versions and which app builds are still calling, which turns "can we remove v1 yet?" into a query instead of an argument.

Limits, validation and abuse

Rate limits are defined as named limiters and can differ by endpoint and by customer plan. Login, registration and password reset get tight limits keyed on both account and IP address. Form requests validate every input and run the policy check before the controller body executes. Endpoints that create something accept an idempotency key where clients may retry on a weak connection, so a double tap does not become a double order.

Docs and tests from the same source

The OpenAPI document is generated from the code and published on every release. Feature tests call each endpoint as each role, assert status codes and JSON structure, and fail the build if a response stops matching the specification. If your consumer is a Flutter app, see how we pair the two on our Laravel backend for Flutter page.

Process

From contract to live endpoints

  1. 1

    Consumers and contract

    We list who will call the API and what they need, then draft endpoints, payloads and error formats as an OpenAPI document you can review.

  2. 2

    Auth and foundations

    Authentication, rate limiters, error handling, pagination and the versioned route structure are built and tested before feature endpoints.

  3. 3

    Endpoints in batches

    Resources, form requests and feature tests are delivered group by group to a staging URL your app or front-end team can build against.

  4. 4

    Integration support

    We work with the consuming developers, adjust the contract where real use exposes gaps, and run load checks on the heaviest endpoints.

  5. 5

    Release and monitoring

    Production deploy with request logging, error tracking and version usage reports, followed by a documented process for future changes.

Deliverables

What the consuming teams receive

  • An OpenAPI document that matches production
  • Feature tests for every endpoint and role
  • A written versioning and deprecation policy
  • Per-device tokens that can be revoked
  • A staging API for your client developers
FAQ

Laravel API questions from product teams

Should our API be REST or GraphQL?
REST is our default on Laravel because the framework's resources, form requests and policies map onto it directly and most clients need nothing more. GraphQL can make sense when many different clients need very different shapes of the same data. We will say which fits after seeing your screens.
Sanctum or Passport: which one do we need?
Sanctum covers most projects: tokens for your own mobile app and cookie sessions for your own SPA. You need Passport when third-party developers will request access to user accounts through OAuth2. If you are unsure, start with Sanctum and add Passport when a real partner integration requires it.
How do you handle users who never update the mobile app?
With versioned endpoints and a minimum-version check. Old builds keep calling the version they were built for. The app sends its build number, and the API can answer with a soft prompt or a required update once a version is finally retired.
Can you add an API to our existing Laravel application?
Yes. If business logic already sits in services or actions, endpoints can reuse it. If it sits in controllers, we extract it first so web and API share one implementation. That preparation is described under Laravel customization.
Will our front-end or mobile team get documentation?
Yes, from the first batch of endpoints. They receive browsable docs generated from the OpenAPI document, a staging base URL, test accounts for each role and a Postman collection. The docs are regenerated on each release so they cannot fall behind the code.
How is the API tested?
Every endpoint has feature tests that authenticate as each role, send valid and invalid input and assert the status code and JSON structure. Rate limits and permission failures are tested too. The suite runs on every pull request.
Do you also build the app that consumes the API?
We can. Our team builds mobile apps in Flutter, React Native and native code, and web front ends in React and Vue. Having both sides in one team shortens the feedback loop, though we are just as happy serving your existing app developers. Our mobile app development page has the details.
Start a project

Need an API your app team can trust?

Tell us who will call it and what it must do. We reply within one business day with a first outline of the contract and a free quote.

  • Free consultation and quote
  • NDA on request
  • You own the source code
  • Reply within one business day
Add budget and timeline optional, helps us quote faster

This form is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.