Laravel Api Logs Laravel Package

Technical Evaluation

Architecture fit

• The package is a single middleware (LogApiRequest) appended to the api group, one published migration, and an ApiLog Eloquent model with a polymorphic causer relation plus an opt-in HasApiLogs trait. It occupies the same integration surface as any first-party middleware — no service container overrides, no queue dependency, no external SaaS contract.
• Writes happen in terminate(), after the response is flushed. Architecturally correct (no user-facing latency in the happy path) but it means one synchronous INSERT against the primary database per authenticated request.
• The trait is opt-in per model. That is good scoping hygiene, but it is also a silent-failure surface: authenticated models without the trait are skipped with no error (since v3.0.0) — a request can be "logged" in the team's mental model and simply absent from the table.
• The notable architectural seam is schema ownership. The migration is publishable — the api_logs table becomes your schema — while the model, casts, and effectively the column contract stay with the vendor. Any future column change becomes an upgrade-coordination event across teams.

Integration feasibility

• Genuinely small effort: composer require, publish + run migrations, append middleware, add trait. For a team already on Laravel 11–13, half a day including verification.
• Redaction-by-default is the feature that lets a TPM approve this without a security exception: credential-type keys recursively, Authorization/Cookie/X-Api-Key/CSRF headers, response bodies (protecting token-issuing endpoints), and stored query strings. v3.1.0 shipped this; v2.1.0 backported it.
• Non-JSON responses are handled (v2.1.1) — relevant for partner/legacy endpoints returning HTML error pages or XML. Streamed/binary responses store response_data = null rather than corrupting the row.
• Configurability is adequate but thin: redaction lists, replacement string, and an auth guard selector (v3.2.0). No sampling rate, no route allow/deny list, no documented per-environment toggle — confirm against the docs site before committing.

Technical risk

• Adoption risk (highest). 0 stars, 0 dependents, single-agency maintainer out of Matosinhos. You are an early adopter of a package whose bus factor appears to be one team. Mitigant: the codebase is small enough to vendor or fork, so the risk is recoverable rather than existential.
• Data-at-rest risk. Redaction is a key-name denylist. A credential accepted under a non-standard key (e.g. x_session, auth_code, free-text notes fields that happen to carry secrets) will persist in plaintext. This is the risk that needs an explicit owner, not a checkbox.
• Compliance exposure. Storing request/response payloads and IPs creates a PII corpus. Retention policy, right-to-erasure handling, and where the table lives are your obligations, not the vendor's.
• Version churn. v3.0.0 was breaking (PHP ≥ 8.2 floor, dropped Laravel 7–10, timing moved into the request attribute bag, typed signatures). Reasonable engineering discipline (Pint, PHPStan level 5, CI matrix across PHP 8.2–8.4 × Laravel 11–13), but a major bump already inside a short history.

Key questions

• Is the api_logs table a system of record for anything (audit, billing, incident forensics), or purely diagnostic? The answer sets the availability bar and the backup strategy.
• What is our retention window, and who owns the purge job? The package ships no pruning command, so this is ours to build.
• Can we tolerate a synchronous INSERT on the primary DB at our peak request rate, or do we need a write-behind path?
• Do we have an internal fork plan (and a named maintainer) if upstream goes quiet for 12 months?
• Which authenticatable models need the trait, and what is the review checklist to ensure new models get it?
• Does our data-residency or privacy posture permit payload storage at all, or is header/metadata logging the ceiling?

Integration Approach

Stack fit

• Requires PHP ≥ 8.2 (≥ 8.3 for Laravel 13) and Laravel 11/12/13. Teams on Laravel 7–10 must pin ^2.0, which is in security-fix-only mode — a strong argument for upgrading the framework first rather than adopting the package on an old stack.
• Any Laravel guard works, with an explicit guard selector available since v3.2.0 — relevant for multi-tenant apps with separate customer/admin/partner authenticatables.
• The HasApiLogs trait + $user->apiLogs relationship gives product-facing value immediately (support can browse a customer's request history without a DBA), which is often the real ROI versus raw log files.

Migration path

1. Framework floor check — confirm PHP and Laravel versions clear the v3 bar. If not, either upgrade or deliberately accept the 2.x security-only track.
2. Config publish — publish the config tag before running migrations so redaction lists are extended to org-specific key names (internal auth tokens, tenant IDs if you treat them as sensitive) prior to first write.
3. Migration publish + review — publish the migration, then inspect the generated schema against your table conventions (indexes, collation, partition strategy) before running it in anything above dev.
4. Middleware placement — append to the api group; verify ordering relative to auth middleware, since logging depends on the authenticated principal being resolved. Where auth is resolved later in the stack, confirm duration and causer are still correct (v2.0.2 fixed a related defect).
5. Trait rollout — add HasApiLogs to each participating model, in a single PR per model, with a test asserting rows appear.
6. Traffic ramp — dev → staging with production-shaped traffic → a single production service or low-traffic route → full api group.

Compatibility

• Clean Laravel-native integration; no framework patching.
• Non-JSON and binary responses are handled, but multi-part uploads and large payloads will inflate row size — decide a size cap or exclusion rule.
• If you run multiple apps against one database, confirm the migration's table name won't collide.
• Coexistence with existing observability (Laravel Telescope, Sentry, access logs) needs a deliberate statement of "this is for X, not Y" or you will pay for the same telemetry twice — Telescope in particular overlaps heavily and is first-party.

Sequencing

• Phase 1 — spike on one non-critical API surface; validate redaction against a real payload capture, not a synthetic test.
• Phase 2 — retention/purge job and a dashboard read path shipped before broad rollout; otherwise the table grows unattended and becomes the incident.
• Phase 3 — extend to all authenticated API surfaces; add the trait checklist to the model-creation template or PR bots.
• Phase 4 (conditional) — vendor-fork decision checkpoint at 6 months based on upstream release cadence and our own issue/PR history.

Operational Impact

Maintenance

• Version support policy is stated (3.x active, 2.x security fixes, 1.x EOL), which is more than most single-agency packages offer. Still, expect to track upstream releases manually — there is no automated bump path for a package with 0 dependents, so nothing will nudge you.
• Schema drift is the recurring cost: publishing the migration means future vendor changes arrive as diffs you must reconcile by hand. Budget a small but recurring slice of every Laravel upgrade cycle.
• Plan for ownership of the purge job, the trait-application checklist, and the config file as internal assets. Three small artifacts, each with a name attached.

Support

• Support channel is a single agency's GitHub issues, backed by a SECURITY.md with private disclosure and a CONTRIBUTING.md. Acceptable for open source, not a commercial SLA — there is no paid support tier, no response-time commitment, no LTS guarantee.
• For a TPM: treat it as "community-supported, agency-maintained." Escalation path for a production blocker is your own engineers reading the source. The source is small enough that this is realistic; a mid-sized package with the same star count would not be.
• Realistically, the team adopting this should designate one engineer as the internal owner/upstream contact.

Scaling

• The synchronous terminate() INSERT is the primary scaling constraint. It sits on the request path for connection/query budget even though it is off the response path. At high RPS, a full-payload table can dwarf the application's own core tables — payload + headers + response bodies per row is not a small row.
• No sampling means volume is 1:1 with authenticated traffic. Absent a route deny-list, health checks and trivial GETs consume storage equally.
• Mitigations are all internal work: prune aggressively, store on a separate connection/table space, index only what the browse UI actually queries, and consider dropping response_data for high-volume endpoints. None of these are package features — they are your roadmap items.
• Redaction is computed in-process per request; negligible versus the DB write, but it does recursively walk request and response payloads, so large bodies carry a CPU cost.

Failure modes

• Silent non-logging — model missing the trait, or auth guard misconfigured. No error, just absence. Monitoring must assert "rows exist for this endpoint," not merely "app is up."
• Log write fails, request succeeds — a DB error in terminate() cannot fail a response that already went out, so gaps are invisible unless alerted on. Conversely, verify it can't surface as a 500 under unusual conditions (connection pool exhaustion).
• Redaction miss — a secret under an unrecognised key name persists. Highest-severity, lowest-visibility failure. Needs a periodic sampled audit of stored rows, not just a code review of the config.
• Unbounded growth — no pruning shipped; disk and query degradation arrive slowly and then abruptly.
• Upstream abandonment — no releases for an extended period. Degrades gracefully (a middleware and a table age well), but blocks framework upgrades eventually. Fork is the escape hatch; keep it cheap by not modifying vendor code.
• PII accumulation — an erasure request that must also clear api_logs, and a causer polymorphic relation that will be orphaned when a user is deleted. Decide cascade behaviour up front.

Ramp-up

• Engineering ramp is genuinely low: one middleware registration plus a trait, well inside a sprint.
• The real ramp cost is governance, not code. Two decisions must be made by someone with authority before rollout: the retention window and the PII classification of stored payloads. Deferring these converts a half-day integration into an unbounded cleanup project.
• Recommend a written "why we run this and what we will never store" note alongside the config, so the next engineer inherits the rationale rather than re-deriving it from a denylist.