Statamic Editor Api Laravel Package

Product Decisions This Supports

• Build vs. buy for mobile editorial tooling. v2.7.0 moves the Editor API back to MIT, so the "buy" side of the equation collapses to zero licence cost. If a roadmap item involves field editing, offline drafting, or editorial approvals away from a desktop, adopting this API plus the official iOS client is now a credible alternative to commissioning a bespoke mobile CMS client.
• Licensing and procurement decisions. The relicence removes per-site fees, licence keys, and Marketplace checkout. That changes the approval path from "vendor contract + legal review + budget line" to "dependency review." Worth re-running any previously deferred evaluation that stalled on cost.
• Multi-CMS strategy. The same HTTP contract now serves Statamic and Drupal 11 (ppcharlier/drupal-editor-api), and the client is a single app, Editor for Drupal & Statamic. If our estate spans both, one client investment covers both backends — relevant to consolidation, migration, and "which CMS do we standardise on" debates.
• API surface vs. bespoke endpoints. Choosing a published contract over hand-rolled mobile endpoints shifts maintenance onto the package and gives us a documented integration boundary between content models and client apps.
• Roadmap sequencing. Because the app is a shipped product rather than a spec, we can validate mobile editorial demand against an existing client instead of funding client development first.
• Use cases to scope against: field reporting and journalism, remote/offline content capture, editorial review on mobile, content ops for staff without desktop access, and light-weight publishing workflows on Statamic-backed Laravel apps.
• Risk posture. Single-maintainer package with a version history that has already flipped licence direction once (MIT → commercial → MIT). That is a governance data point for any dependency policy, independent of the code.

When to Consider This Package

Consider it when:

• The stack already runs Statamic on Laravel (or Drupal 11), and content authors need a native mobile editing surface.
• You want an off-the-shelf API contract rather than designing and maintaining a mobile content API in-house.
• Licence cost or procurement friction was the reason a prior mobile-editorial idea was shelved — that objection no longer applies from v2.7.0.
• You need parity across Statamic and Drupal sites with one client app, or you anticipate migrating between them.
• You can absorb small-vendor risk: pin the version, review the API and auth model before exposing it beyond the internal network, and be prepared to fork (MIT permits it).

Look elsewhere when:

• You are not on Statamic or Drupal — this is not a general-purpose headless CMS API.
• You need enterprise support, an SLA, or a multi-maintainer guarantee; nothing in this release addresses that.
• The requirement is SSO, granular editorial roles, audit trails, or compliance features at a depth the package does not document — those would need to be built or bought separately.
• You already operate a custom editorial API that satisfies the workflow; migrating is unlikely to pay back.
• You are running v1.2.3–v2.6.1. Those versions stay under the commercial licence — do not assume the MIT terms retroactively.

How to Pitch It (Stakeholders)

For executives: a one-line summary — the mobile editing layer for our CMS is now free and open source. As of v2.7.0 the Editor API is MIT licensed: no per-site fee, no licence key, nothing to purchase. It plugs into the Laravel/Statamic stack we already run, and the companion iOS app covers both Statamic and Drupal 11, so a single client investment spans our content platforms. The decision required is small — an engineering dependency review, not a procurement cycle — and the downside is bounded because MIT lets us fork if the maintainer stops shipping. Main caveat to flag: it is a small, single-maintainer project, and earlier versions (v1.2.3–v2.6.1) remain commercially licensed, so we should confirm which version we intend to standardise on.

For engineering: this release is licensing and positioning, not new capability — no breaking changes, deprecations, or new endpoints are announced. Practical impact: we can vendor or fork without legal friction; we should pin to a specific v2.7.x tag; and we should audit the API's authentication and exposure model before it reaches production, since the package opens an editorial write path into content. Reusing the shared Drupal/Statamic contract is the main architectural upside — treat the contract as the integration boundary and keep our own client-side abstraction thin so a future swap stays cheap.