Rest Laravel Package

Product Decisions This Supports

• Build vs. buy for the integration surface. If we are on Ibexa DXP, this package is the vendor-supported API layer. Choosing it means we do not staff a bespoke content API — we consume a contract Ibexa maintains, and we spend our engineering budget on product surface instead of plumbing.
• Headless / API-first roadmap. The v5 line has been converging on OpenAPI-compatible endpoints (location move/swap/copy, content copy, publish content/version/type/role, restore trash, create draft from version) plus /languages, current-user/session routes, and token-based auth. That makes this a credible backbone for decoupled frontends, partner portals, and mobile clients — and it makes generated client SDKs and contract tests feasible.
• Third-party and partner access. Exposing REST instead of granting CMS access turns an "integration project" into a documented, versioned, rate-limitable contract. Useful when we need to negotiate SLAs or scope support boundaries with agencies and partners.
• Automation, migration, and ETL. Content migration, bulk content-type changes, DAM/PIM sync, and reporting extracts can be driven from CI jobs and scripts rather than one-off admin work. Recent criterion/sort-clause parser work (ContentName, FileSize, Image, ContentTypeGroupName, IsBookmarked) directly expands what those jobs can query — worth tracking against our backlog.
• Roadmap sequencing input. Because this ships as split subpackages of the DXP with parallel 4.6 and 5.0 branches, its feature set tracks their release train, not ours. Any decision that assumes a REST capability needs a written dependency on a specific DXP version — treat it as an external commitment, not an internal estimate.
• Security/identity decisions. Reworked Symfony authenticator-based auth under a separate firewall, a dedicated token service, X-Expected-User header checking, and the v5.0.8 "remove auth token on logout" fix are all inputs to our session-handling and SSO posture. The logout-token fix is the kind of item that should prompt a review of our own token lifecycle assumptions.

When to Consider This Package

Adopt when:

• We are already running (or are committed to) Ibexa DXP — this bundle is part of the distribution, not an optional add-on we evaluate in isolation. "Adoption" is really a question of standardizing on the REST API rather than writing custom controllers or direct DB access.
• We need programmatic CRUD over content, content types, locations, users, roles, and trash with vendor support behind it.
• We want an OpenAPI-shaped contract for generated clients, mock servers, and contract tests.
• We are on PHP 8.3+ / Symfony 7.x (v5 requires PHP 8.3 and bumped to Symfony 7.4 LTS) or on the 4.6 LTS branch and need a supported upgrade path rather than a rewrite.
• Legal has cleared the dual license.

Look elsewhere when:

• The application is a plain Laravel app with no Ibexa DXP behind it. This is a Symfony bundle bound to Ibexa core services; it is not a drop-in Laravel package and there is no meaningful path to using it standalone. Do not put it on a Laravel roadmap.
• We need permissive licensing (MIT/Apache) or GPL is unacceptable for distribution. See the licensing caveat below.
• We need event-driven or push semantics — webhooks, subscriptions, streaming. REST is pull-based; that gap has to be filled by other means and should be scoped explicitly.
• We need high-frequency, low-latency reads on the critical path. A REST hop over a full DXP stack is the wrong tool; use the underlying search/content services or a read model.
• We need a standalone PHP SDK to hand to a partner. That is a different artifact — the REST reference and client libraries, not this server-side bundle.
• We are not prepared to track the DXP release train. The API surface is versioned by DXP release, and the package has no independent semver meaning.

Caveats a PM should put in writing before sign-off:

• License is the gating item, not the code. The repo metadata reports NOASSERTION, and the README describes a split regime: the Ibexa Business Use License v2.4+ (granted only with a valid DXP subscription) and GPL v2. Automated license scanners will flag this. GPL-2.0 copyleft is a real constraint if we distribute anything derived from it. Get a written legal opinion before it enters the dependency tree — do not let this be resolved by an engineer's composer require.
• The popularity signals are misleading, and that cuts both ways. 5 stars and 0 tracked dependents look alarming, but this is a monorepo-split subpackage installed via the DXP metapackage, so it ships in every Ibexa install regardless of GitHub metrics. The honest read: do not cite stars as evidence of quality or of risk, and equally do not cite the install base as evidence of fitness — nobody is filing GitHub issues here, so our only real signal is Ibexa's commercial support channel and their release history.
• Support relationship, not community. Bug fixes and CVEs flow through the Ibexa subscription and their issue tracker. If we are on GPL-only without a subscription, our effective support model is materially weaker than the release cadence implies.

How to Pitch It (Stakeholders)

To executives: This is the vendor's supported way to expose our Ibexa content platform to other systems — web frontends, mobile apps, partner portals, internal automation. Choosing it over a custom-built API is a buy-over-build call: it removes a bespoke integration layer from our maintenance burden and puts the contract under vendor support and a published release cadence. The strategic payoff is optionality — a documented API means we can change frontends, add channels, and onboard partners without re-platforming. One decision needs to land first: licensing. The package is dual-licensed (commercial Ibexa license or GPL v2), and it only makes business sense alongside a DXP subscription. That is a commercial conversation, not a technical one, and it should happen before we commit engineering time.

To engineering: Treat this as the DXP's REST bundle, not a general PHP library — it is Symfony-coupled and has no standalone life in our Laravel services. If we standardize on it, we get OpenAPI-compatible endpoints for the major content and location operations, token-based auth under a dedicated firewall, and expanded search criteria/sort-clause support. Two things to plan around: (1) we are pinned to their release train — v5 requires PHP 8.3+ and follows Symfony 7.4 LTS, with a parallel 4.6 branch, so our upgrade calendar inherits theirs; (2) the API is pull-based, so anything needing push/events is out of scope and needs a separate design. Also budget for contract tests against the published spec — that is our only defense against quiet surface changes between DXP minor versions.

To legal/procurement: Dual license — Ibexa BUL v2.4+ (requires an active DXP subscription) or GPL v2. Repo license metadata reads NOASSERTION, which will trip scanning tools; that is a metadata artifact, not an unknown, but it needs a documented resolution. Confirm whether our use constitutes distribution and whether the GPL path is viable for the products in scope.