Architecture

REST API First: WordPress vs Laravel with Sanctum and Scramble

By Lara Dashboard 5 views
REST API First: WordPress vs Laravel with Sanctum and Scramble
Your product needs a REST API that other apps and clients will call every day. Mobile, a React admin, partner integrations, and maybe a headless front end. Someone on the call asks if the WordPress REST API is enough, or if you should build API-first on Laravel with Sanctum and proper OpenAPI docs.
This article compares the WordPress REST API (and common auth and plugin patterns) with Laravel's API-first stack using Sanctum for auth and Scramble for OpenAPI documentation. You will see where each stack fits for product APIs and headless admin work, and where the glue starts to cost more than the code.
Disclosure: LaraDashboard is our open-source Laravel admin and CMS. We recommend it when you want a Laravel foundation that is friendly to APIs, roles, and modular admin work. It is not a full API gateway. The comparison below still helps if you use Filament, Nova, or a custom Laravel app.
Related reading: headless WordPress vs Laravel CMS, custom post types vs Laravel models, building a multi-tenant SaaS: Laravel vs WordPress Multisite, Laravel vs WordPress, auth, 2FA, and session security for a self-hosted Laravel CMS, and firewall, WAF, and rate limiting for self-hosted LaraDashboard.

The short answer

WordPress REST API fits when your primary content already lives in WordPress and clients mostly need posts, pages, media, and custom post types as JSON. Core gives you /wp-json/ routes. Auth often means application passwords, cookie/nonce flows for same-origin admin, or JWT and OAuth plugins for external clients. You can ship a headless front end quickly. Product-shaped APIs (orders, workspaces, meters, complex write rules) usually grow into custom endpoints, plugins, and capability checks that feel bolted on.
Laravel with Sanctum (and Scramble) fits when the API is the product surface. You define routes, form requests, policies, and resources in application code. Sanctum covers SPA cookie auth and API tokens for first-party mobile or partner clients. Scramble (or similar) generates OpenAPI from your code so docs stay close to the handlers. You own versioning, rate limits, and test coverage like other product code.
If you are exposing a blog and a few CPT fields to a Next.js site, WordPress REST can be enough. If clients pay for API access to your domain model, plan for Laravel (or another application framework). Do not stretch WP-JSON into a billing and permission platform and hope plugins fill every gap.

What the WordPress REST API actually gives you

WordPress ships a REST API under the /wp-json/ prefix. Core registers routes for posts, pages, users, media, comments, taxonomies, and more. Plugins and themes can register custom routes with register_rest_route. Official developer docs live on WordPress.org REST API Handbook.
That model is excellent for:
  • Headless marketing sites and blogs that still edit in wp-admin
  • Mobile or SPA readers that mainly consume published content
  • Light write flows (create a post, upload media) with careful capability checks
  • Teams that already run WordPress and need JSON without a full rebuild
It is a weaker fit when each client needs:
  • Stable versioned product endpoints that are not "posts with meta"
  • Fine-grained authorization beyond WordPress capabilities
  • First-class token lifecycle (issue, rotate, revoke, scope) for many third parties
  • OpenAPI that matches handlers without hand-maintained Swagger files
  • High write throughput with domain invariants (inventory, seats, ledger entries)
The REST API is still WordPress. Your data model is still posts, meta, and options unless you build custom tables. Custom endpoints help. They do not turn CPT meta into a typed domain layer by themselves. See our notes on custom post types vs Laravel models when plugin growth stops matching product data needs.

Auth patterns on WordPress APIs (and the usual pain)

WordPress offers several auth paths. Pick the wrong one and you get cookie CSRF bugs or tokens that never expire cleanly.
Cookie + REST nonce (same-origin). Classic for themes and admin-adjacent SPAs on the same site. The browser sends cookies. You pass a REST nonce. This is not a great fit for native mobile apps or third-party servers.
Application passwords. Built into modern WordPress for basic auth over HTTPS to the REST API. Good for personal scripts and simple integrations. Awkward as a multi-tenant partner platform. Rotation and scoping are limited compared to a product token model.
JWT and OAuth plugins. Common for headless and mobile. Quality varies by plugin. You inherit plugin update risk, secret handling, and claim design. Some teams run this well. Others discover expired libraries and unclear refresh flows under load.
Custom permission_callback on every route. Required for anything serious. Missing or weak callbacks are a classic footgun. Capability checks must match who can read drafts, who can write meta, and who can hit custom actions.
Honest takeaway: WordPress can authenticate REST clients. The story is fragmented across core features and plugins. Product teams often want one token and policy model that matches their User and Role tables, not a mix of capabilities, plugin claims, and application passwords.
For a broader security cost view on WordPress vs owning a Laravel stack, see WordPress security maintenance cost vs Laravel ownership.

What Laravel API-first usually means

In Laravel, an API-first app treats HTTP JSON as a first-class interface. Typical pieces:
Routes and controllers (or invokable actions). You declare /api/v1/... routes. Middleware stacks handle auth, throttling, and tenant context if you need it.
Eloquent models and API resources. Models hold domain data. API resources (or Fractal-style presenters) shape JSON. You avoid leaking internal columns by default.
Form requests and validation. Input rules live next to the handler. Invalid payloads fail with consistent 422 responses.
Policies and gates. Authorization sits in code you can unit test. Roles can come from Spatie Permission or your own tables. See role-based access control with LaraDashboard.
Versioning. Prefixes (v1, v2) or header schemes you choose and document. Deprecation becomes a release process, not a plugin changelog surprise.
Laravel does not magically make a good API. It gives you a place to put the rules. Product APIs succeed when those rules are explicit and tested.

Sanctum: SPA cookies and API tokens

Laravel Sanctum is Laravel's first-party package for simple API authentication of SPAs, mobile apps, and token-based APIs.
Two common modes:
SPA authentication. Your front end (often on a subdomain) uses cookie-based session auth after a CSRF cookie handshake. Sanctum treats the SPA as a first-party citizen. Good for admin UIs and same-product SPAs.
API tokens. Users (or clients) get personal access tokens stored as hashes. Tokens can have abilities (scopes). Mobile apps and server-to-server callers send Authorization: Bearer .... You revoke tokens in your database when a laptop is lost or a partner offboards.
Sanctum is not OAuth2 authorization-server completeness. If you need full OAuth grant types for many third-party developers, look at Laravel Passport or a dedicated IdP. Many product APIs never need that. First-party SPA plus scoped tokens covers a large share of B2B admin and mobile cases.
Pair Sanctum with rate limiting, HTTPS only, and short-lived tokens where your threat model needs it. Our auth, 2FA, and session security and firewall, WAF, and rate limiting pieces cover the ops layer around the app.

Scramble and OpenAPI: docs that track the code

Partners and frontend teams ask for OpenAPI (Swagger) specs. Hand-written YAML drifts. Code-first generators reduce that drift.
Scramble is a popular Laravel package that generates OpenAPI documentation from your routes, requests, and related code. Other options exist (for example L5-Swagger annotations). Pick one and make CI fail when the published spec and routes disagree.
Why this matters next to WordPress:
  • WP-JSON exposes an index of routes. That helps discovery. It is not the same as a maintained OpenAPI contract with request and response schemas for your product resources.
  • Plugin endpoints appear and disappear with plugin state. Client SDKs break without a version story.
  • Laravel + Scramble (or similar) keeps the contract next to FormRequest rules and resource shapes you already own.
Docs do not replace tests. They help clients onboard and catch breaking changes earlier. Use both.

Comparison: content JSON vs product API

WordPress. Best default payload is content: title, content blocks or HTML, featured media, taxonomies, author. ACF or similar can expose fields. Clients learn WP conventions. Product invariants (cannot oversell seats) live in custom PHP you bolt onto rest_pre_insert_* hooks or custom routes.
Laravel. Best default payload is your domain: Workspace, InvoiceLine, DeviceRegistration. Content can still exist as models. The API is shaped for the product, not for the CMS post object.
If your roadmap is mostly "render CMS content in an app," WordPress REST or headless WP is rational. If your roadmap is "mobile completes workflows that mutate business state," Laravel resources and policies fit better. Headless WP alone does not invent product tenancy or billing APIs; see headless WordPress vs Laravel CMS.

Comparison: auth and client types

Same-origin admin SPA. WordPress cookie + nonce, or Laravel Sanctum SPA mode. Both can work. Laravel keeps policies in one place with the rest of the app.
Mobile first-party app. WordPress: JWT/OAuth plugins or application passwords (awkward at scale). Laravel: Sanctum tokens with abilities, revoke on logout or compromise.
Partner integrations. WordPress: often custom plugin + application passwords or OAuth plugin. Laravel: tokens or Passport/IdP when you need full OAuth. Issue, rotate, and audit in your own tables.
Machine-to-machine. Prefer explicit client credentials or signed server tokens. Avoid long-lived user passwords in CI. Sanctum personal tokens can work for simple M2M; evaluate Passport or an IdP when partners multiply.

Comparison: versioning, errors, and rate limits

Versioning. WordPress namespaces help (namespace/v1). Breaking changes still surprise clients when plugins update. Laravel route prefixes and resource versioning are ordinary release work.
Errors. WP-REST returns WP_Error shaped JSON. Laravel tends toward consistent exception rendering (401, 403, 404, 422, 429). Pick a shape and stick to it in both stacks.
Rate limiting. WordPress hosts and security plugins offer limits; quality varies. Laravel throttling middleware is first-class on routes. Combine app limits with edge WAF rules when you are public.

Comparison: testing and CI

WordPress REST tests exist (PHPUnit, integration tests), but many WP projects under-test custom routes. Plugin interactions are hard to fixture.
Laravel feature tests can hit JSON endpoints with actingAs users and assert status plus JSON paths. Sanctum has testing helpers. CI can regenerate OpenAPI and diff it. That workflow matches how product teams already ship Laravel apps.
If your team will not write API tests, neither stack saves you. The Laravel tooling makes the happy path easier to automate.

Prose cheat sheet: WordPress REST vs Laravel Sanctum + Scramble

Best default use. WordPress REST: headless content, CPT-driven JSON, editors in wp-admin. Laravel Sanctum + Scramble: product APIs, first-party SPA/mobile, documented partner endpoints.
Data model. WordPress: posts, meta, options, custom tables as exceptions. Laravel: Eloquent models and migrations as the default.
Auth. WordPress: cookies/nonce, application passwords, JWT/OAuth plugins. Laravel: Sanctum SPA cookies and API tokens; Passport/IdP when full OAuth is required.
Docs. WordPress: route index + manual or plugin Swagger. Laravel: Scramble or annotation generators next to FormRequests.
Authorization. WordPress: capabilities and permission_callback. Laravel: policies, gates, optional Spatie roles.
Extensibility. WordPress: plugins registering routes. Laravel: Composer packages and app modules with CI. See also building modular Laravel applications with Lara Dashboard.
When to stop. WordPress: when clients need a stable product contract, scoped tokens, and domain writes that are not CPT-shaped. Laravel: when you only needed a headless blog and overbuilt an API platform.

When WordPress REST still fits

Choose WordPress REST when most of these are true:
  • Editors must stay in wp-admin
  • Clients mainly read (and lightly write) content and media
  • Custom fields map cleanly to CPT meta or a small plugin
  • You can accept plugin-based JWT/OAuth if mobile needs tokens
  • Your team already operates WordPress well
  • Failure is a broken page fetch, not a corrupt ledger
Examples: headless marketing sites, magazine apps, simple content portals. Pair with caching and careful auth. Do not pretend WP-JSON is your billing system.

When Laravel Sanctum + Scramble fits

Choose Laravel when most of these are true:
  • The API encodes product rules and workflows
  • You need SPA cookie auth and mobile tokens in one coherent model
  • OpenAPI must track handlers for partners and internal clients
  • RBAC is product-shaped, not only Editor/Author/Admin
  • You want feature tests and CI around every breaking change
  • Your team ships Laravel (or will hire for it)
Start with a vertical slice: auth -> one resource CRUD -> OpenAPI -> rate limit -> revoke token. Add versioning before the second mobile client ships. If multi-tenant workspaces enter the chat, design tenant context on day one; see multi-tenant SaaS: Laravel vs WordPress Multisite.

Honest failure cases

WordPress REST failures we see teams hit:
  • Custom routes without strict permission_callback expose drafts or actions
  • JWT plugin abandoned or misconfigured refresh flows
  • Application passwords shared in Slack and never rotated
  • ACF/field plugins change response shapes under editors' feet
  • Headless cache serves private content after a permission change
Laravel API failures we see teams hit:
  • Tokens without abilities (everything is admin) and no revocation UI
  • SPA CORS and Sanctum domain misconfig that "works on localhost" only
  • OpenAPI generated once and never updated in CI
  • Missing policies on a new controller action
  • Throttle limits only in the app while the edge allows floods
Neither list is about fear. Both are about matching the tool to the client contract you owe.

Where LaraDashboard fits (disclosed)

LaraDashboard is a Laravel admin and CMS foundation: posts, roles, modules, and related product pieces you can self-host. Teams use it when they want Laravel ownership for content and admin workflows instead of stretching WordPress plugins and WP-JSON into a product API.
For REST API first work, treat LaraDashboard as a starting admin/CMS layer on an API-friendly Laravel stack. You still design your /api routes, Sanctum setup, policies, and OpenAPI generator (Scramble or another). We do not claim LaraDashboard replaces Sanctum or ships every partner OAuth flow out of the box. You gain a Laravel codebase, modular admin patterns, and a place to hang documented APIs next to CMS content. Explore the product at laradashboard.com.
If you only need headless content from an existing WordPress editorial team, WP REST may stay simpler. If you are building product APIs and already prefer Laravel, start with Sanctum and a docs generator, and use LaraDashboard where an admin/CMS foundation saves time.

FAQ

Is the WordPress REST API good enough for a mobile app?

For content-heavy apps, often yes. For apps that mutate business state with strict rules, you will build many custom endpoints and auth glue. Measure the custom surface before you commit.

Is Sanctum the same as OAuth2?

No. Sanctum covers SPA cookie auth and simple API tokens well. Full OAuth2 authorization server features are closer to Laravel Passport or an external IdP. Choose based on how many third-party developer grant types you must support.

Do I need Scramble specifically?

No. You need some OpenAPI workflow that tracks code. Scramble is a strong Laravel option. Annotations or other generators can work if CI enforces freshness.

Can I use WordPress as CMS and Laravel as API?

Yes. Some teams keep editorial in WordPress and run product APIs in Laravel. You then own sync, SSO, and dual ops. That split is valid when editorial tooling must stay WP. It is dual complexity. Do not invent the split if one stack covers the job.

How does this relate to headless WordPress?

Headless WordPress uses WP as a content API for a separate front end. That is a strong CMS pattern. It is not automatically a product API platform. Read headless WordPress vs Laravel CMS.

Where should we start this week?

List your top ten endpoints and who calls them (SPA, mobile, partner). Mark each as content-shaped or product-shaped. If most are content-shaped and editors live in WP, spike WP REST with the strictest auth you can operate. If most are product-shaped, spike Laravel: Sanctum token -> one resource -> Scramble (or similar) -> feature test -> revoke path. Write the threat model for token theft before you launch.

Ending note

WordPress REST is a strong content JSON interface. Laravel with Sanctum and an OpenAPI generator is a strong path for product APIs. Confusing the two burns client goodwill when shapes and auth change without a contract. Match data model, auth, docs, and tests to the clients you actually ship.
If you want a Laravel admin and CMS foundation to extend beside an API-first app, start at https://laradashboard.com. Bring your own Sanctum and OpenAPI setup. Keep WordPress REST for the content APIs it already serves well.
Back to Blog

Try Lara Dashboard for Free

Explore every feature live — no sign-up required.

Launch Live Demo