ppcharlier/statamic-editor-api
Statamic Editor API adds API endpoints for Statamic's editor, letting custom frontends and headless setups fetch and update editor content programmatically. Integrates with your Laravel app to expose editor data outside the control panel, simplifying headless editing workflows.
Architecture fit. This is a Statamic addon (PHP, runs inside a Laravel application) that exposes a content-editing API consumed by a first-party iOS client, Editor for Drupal & Statamic. It is not a general-purpose Laravel package: it only adds value if we run Statamic as our CMS. For a plain Laravel application without Statamic, the only relevance is the sibling ppcharlier/drupal-editor-api module, which implements the same contract on Drupal 11 — useful if we want one mobile editing client across two CMS estates, not otherwise. The architectural bet is "mobile-native editorial workflow against a headless-ish CMS API," which suits content teams that publish from the field and dislike the Statamic control panel on tablets.
Integration feasibility. Mechanically straightforward: Composer install, publish config, register routes and an auth guard, scope which collections/blueprints are exposed, and configure asset containers for media upload. The real integration surface is the contract between addon and iOS app, plus auth token issuance, CORS, and media transformation. None of that is described in these release notes, so feasibility is unproven until we read the addon source — which, post-v2.7.0, we can legally do without a licence review.
Technical risk. Low code risk from this release: v2.7.0 is a licence change plus documentation clarification, with no indicated breaking changes, deprecations, or API surface changes. The dominant risks are structural, not version-specific:
Key questions. Which Statamic and Laravel/PHP versions are supported, and what is the upgrade policy across Statamic majors? What is the authentication model (Sanctum, custom tokens, per-user scoping) and how are tokens revoked? Is the API contract versioned, and how does the app negotiate addon version? How are drafts, revisions, and concurrent-edit conflicts handled? Are asset uploads and image transforms handled server-side, and with what size/timeout limits? Does the Drupal module share the identical schema, and is that schema documented as a spec? Is the iOS app free, paid, or requiring an account? Who is accountable for the app's App Store lifecycle?
Stack fit. Assumes Statamic 4/5 on Laravel 10/11 and PHP 8.1+. Fits cleanly if Statamic is already our CMS and we want a native mobile editing channel; it is redundant if our editors are desktop-based and happy in the control panel, and it is not applicable to non-Statamic Laravel apps.
Migration path. For teams already on a commercial version, the upgrade is a routine composer update plus removal of the licence key from environment configuration — the notes indicate no code-level changes, so risk is concentrated in procurement, not engineering. For teams on ≤v1.2.2, this is a non-event; stay put or upgrade for parity with the app. For new adopters, start directly on v2.7.0 and never introduce a licence key.
Compatibility. Two matrices must be tracked, not one: addon ↔ Statamic/PHP, and app version ↔ addon version. The second is undocumented in these notes and is the more brittle of the two. If we also run Drupal, validate that both implementations honour the same contract before committing to a single client.
Sequencing.
Maintenance. We own it now. MIT means we can fork, which is both the mitigation and the trap — plan for a named internal owner and a patching cadence, and treat the addon as a dependency requiring review at each Statamic major. Expect to read the source at least once; the licence change makes that free and unencumbered.
Support. Effectively community-only. GitHub issues and the maintainer's discretion. There is no commercial escalation path and no SLA, so incidents in the editorial workflow must be resolvable in-house or worked around via the control panel. Budget for that capability rather than assuming it.
Scaling. Authed API routes bypass Statamic's static caching, so every editor interaction is a PHP-FPM request against the content store. The hot spots are media upload and image transformation, not JSON payloads. Expect to need rate limiting, upload size caps, queue-backed transforms, and a CDN in front of asset delivery. Editorial concurrency is low — tens of simultaneous editors, not thousands — so scale risk is modest and mostly about large assets.
Failure modes. App Store removal or abandonment of the iOS client; app update lagging an addon API change; auth token leakage or stale tokens without a revocation story; upload timeouts on poor mobile networks losing editor work; Statamic major upgrade breaking route registration; a teammate "upgrading" a commercial fork and creating licence ambiguity. The last is the most preventable and the most likely to be discovered late.
Ramp-up. For a Laravel developer already fluent in Statamic, roughly a day to read the addon and understand the contract, and one sprint to integrate, test against the app, and document. Editors need a short onboarding session on the mobile workflow and clear guidance on when to fall back to the control panel. The Drupal module, if in scope, adds a separate integration track with a different skill set and should not be assumed to be a drop-in equivalent without contract testing.
How can I help you explore Laravel packages today?