Core Api Laravel Package

Product Decisions This Supports

• Legacy-application disposition (keep / freeze / retire). This is the primary decision. If graham-campbell/core-api appears in a Laravel 4.1/4.2 codebase, it is a verifiable marker that the service runs on a runtime (PHP 5.x, Laravel 4.x) with no security support since 2018. That elevates the question from "should we fix this bug" to "should this service still exist in its current form" — a portfolio-level call, not a ticket.
• Roadmap sequencing and upgrade funding. It converts "we should modernize someday" into an estimable, closeable line item: replace the deprecated client with a first-party wrapper — 1–3 engineer-days. That estimate is defensible because the package is thin transport plumbing, not business logic. Attach it to the Laravel upgrade path rather than funding it as a standalone initiative.
• Build vs. buy vs. adopt. The answer is build a thin in-house client; do not adopt. The package is an archived artifact under an explicit GrahamDeprecated org with zero stars, zero dependents, and no maintainer. There is no procurement, license negotiation, or vendor evaluation to run. Close the evaluation and move on.
• Third-party dependency risk review (acquisition, security audit, SOC2/ISO evidence gathering). This is exactly the class of finding auditors and acquirers surface: an unmaintained dependency on an EOL runtime with no upstream security response path. Pre-cataloguing it and scoping remediation de-risks diligence and shortens questionnaire cycles.
• Use-case validation / "should this be a product?" The description claims a "clean foundation for exposing a JSON API," but the technical read shows a config-driven HTTP client wrapper for one upstream. That mismatch is the lesson worth internalizing: generic transport plumbing has no standalone product value once the framework provides it first-class. Useful case study for evaluating future "shared foundation" libraries.
• API contract ownership. The genuinely valuable asset is the upstream Core API contract — endpoints, auth model, error shapes, rate limits. Product should decide who owns that contract and whether the vendor still operates the service, independent of which code calls it. That decision outlives this dependency.

When to Consider This Package

Consider it only as an inventory item, never as a dependency choice.

• Legacy Laravel 4.1/4.2 apps that already depend on it and cannot be upgraded within the current planning horizon — and even then, treat it as a defect to schedule, not a platform to build on.
• Dependency audits ahead of a migration, security review, acquisition, or compliance certification — a high-signal finding worth logging and remediating.
• Forensic use: reading the source to reconstruct the upstream Core API's request shapes, headers, and auth flow when no OpenAPI spec or vendor documentation exists. The code is evidence.
• Temporary containment inside an isolated legacy service, with the repository mirrored to internal VCS and exact versions pinned — because an archived repo can vanish from Packagist and silently break reproducible builds and onboarding.

Look elsewhere — specifically, do not adopt — when:

• Any new Laravel project, or any Laravel version beyond 4.x (5.x through 11/12, PHP 8.1+). Composer will hard-conflict on illuminate/* 4.x constraints; there is no tagged compatible release and no maintainer to produce one.
• Any product with a security-patching, SLA, or long-term-support expectation. PHP 5 and Laravel 4.2 are both EOL; every latent CVE becomes your exposure with no upstream fix path.
• Anywhere a first-party client on Laravel's Http facade or Guzzle 7 would work — which is everywhere. The realistic replacement is 50–150 lines of code behind an interface you own.
• Any case where you need documented behavior beyond the README. Rate limits, retry semantics, token refresh, and error contracts are undocumented and must be reverse-engineered from source either way — so you may as well own the code that encodes them.

How to Pitch It (Stakeholders)

To executives: We found a deprecated Laravel 4.x package in our dependency inventory. It is an abandoned artifact — archived under an explicit deprecation organization, zero adoption, no maintainer, no security response process — sitting on a PHP runtime with no security support since 2018. It should not appear in any roadmap commitment. The recommended action is a small, bounded remediation: reimplement its handful of HTTP calls as first-party code and delete the dependency. Estimated effort is a few engineer-days, not a multi-sprint project, and it removes a standing audit and diligence finding.

To engineering leadership: Treat this as legacy-only and reference-only. If it appears in a codebase, scope its removal as part of the Laravel upgrade rather than investing in extending or standardizing on it. The migration is mechanical: extract endpoints, auth headers, and error handling from the source; wrap a new client behind an interface we own so no call site sees the transport; add timeouts, retries, logging, and alerting; then delete the dependency. Two operational guardrails in the interim — mirror the repo internally and pin exact versions with a committed lockfile, because the Packagist entry can disappear and take reproducible builds with it.

To the team / framing: The pitch is not "adopt this package." It is "we have a concrete, cheap, well-scoped piece of dependency hygiene that also unblocks modern infrastructure." Avoid framing it as a rewrite of business functionality — it is a contained replacement of transport plumbing, and the real deliverable is a documented API contract we own instead of one buried in abandoned code. The layering pattern the package encodes (facade → service → domain, vendor quirks confined to a subclass, transport hidden behind an interface) is worth keeping; the implementation is not. Frame the outcome as "we keep the good idea and drop the artifact."