Laravel Api Logs Laravel Package

Product Decisions This Supports

• Build vs. buy for API request auditing. Replaces a bespoke "log every API call" ticket. The scope is narrow and well-defined — middleware + migration + Eloquent model + polymorphic causer — so "buy" here means adopting ~a few hundred lines of MIT code instead of a sprint of internal work. Estimate the build honestly first: a competent Laravel dev can replicate the capture path in 1–2 days, but redaction-by-default, non-JSON response handling, and the guard configuration are where the real effort and the real bugs live.
• Customer-facing support and debugging capability. Every authenticated request is stored with URL, method, IP, redacted payload, headers, response, and duration, browsable via $user->apiLogs. This directly serves support workflows ("what did the customer's integration actually send?") and integration/partner onboarding, where the failure is usually on the caller's side.
• SLA and performance triage. Duration is captured per request, so slow endpoints can be identified from real traffic rather than from APM sampling alone. Adequate for a small-to-mid API; not a substitute for an APM product.
• Compliance and incident response posture. Redaction happens before persistence — credential-type keys recursively, Authorization/Proxy-Authorization/Cookie/X-Api-Key/CSRF headers, response bodies (protecting token-issuing endpoints), and query strings in the stored URL. That moves "we log request bodies" from a security exception to a reviewable default, which is typically the gating decision for an audit-log feature.
• Roadmap sequencing. This is a plausible prerequisite for later features: per-user API usage dashboards, rate-limit justification, abuse investigation, deprecation planning ("who still calls v1?"). Adopting it now means the data exists when those conversations start.
• Buy-in for a "sensitive data must be queryable" policy. The publishable config for redaction lists and replacement string lets Security own the denylist as configuration rather than as code review.

When to Consider This Package

Consider it when:

• You run a Laravel 11–13 / PHP 8.2+ API (v3.x only; 2.x is security-fix-only for Laravel 7–10) and want per-user request history without standing up a logging pipeline.
• Your primary need is "what did this specific authenticated user send and receive?" rather than aggregate metrics, tracing, or alerting.
• Write volume is modest. Capture is synchronous in terminate() — correct for latency, but it is one INSERT per authenticated request against your primary database. At high request rates this is a data-growth and index-maintenance decision, and the README documents no sampling rate or route allow/deny list. Verify those against the docs site; if they don't exist, plan a retention/purge job before launch.
• Your auth model is standard (any Laravel guard, configurable since v3.2.0) and you can accept the HasApiLogs trait being opt-in per model — with the documented consequence that authenticated models lacking the trait are silently not logged. That is a safe failure mode but a real observability gap; know which models you expect to appear.
• You are comfortable being an early adopter. Zero stars and zero dependents with a single-agency maintainer means you should treat the code as vendorable: small enough to fork, pin a version, and own if the agency stops shipping.
• You are willing to own the schema. The migration is publishable, so the table is yours, but the model and casts stay with the vendor — every future column change becomes an upgrade coordination event.

Look elsewhere when:

• You need aggregate analytics, tracing, or alerting — this is per-request storage, not an observability platform; pair it with or replace it by APM/structured logging.
• You have high-throughput or spiky traffic and no appetite for a per-request DB write.
• Your sensitive data doesn't live under conventional key names. Redaction is a key-name denylist; a credential arriving as x_custom_auth or embedded in a free-text field will be stored in plaintext. That is the risk to escalate to Security before, not after, adoption.
• You need strict vendor SLAs or long-term support commitments — this is a friendly agency OSS project, not a commercial product.
• You are on Laravel 10 or below and unwilling to run a security-fix-only branch.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed, drop-in component that gives us a per-customer record of every authenticated API call — what was sent, what came back, how long it took — with credentials automatically stripped before storage. It costs roughly half a day of engineering to adopt, requires no new infrastructure or vendor contract, and closes a recurring support gap where we currently cannot answer "what did their integration actually send?" It is small enough to fork and maintain ourselves if the upstream project stalls, so the downside is bounded. The one thing to fund alongside it is a retention policy, since it adds a row per API request.

For engineering: One middleware appended to the api group, a published migration, and a HasApiLogs trait on the authenticatable model. No container overrides, no queue, no external service. Capture runs in terminate() after the response is sent, so no user-facing latency — but it's a synchronous INSERT per authenticated request, so we own a growth curve and a retention job. Redaction is on by default (recursive key denylist for request/response/query string, header denylist for auth/cookie/API-key/CSRF), configurable via a publishable config file. We should pin the version, review what the denylist misses against our actual payload shapes, and be aware that the migration is publishable — meaning we own the table but the model and column contract stay upstream, so upgrades need coordination.

Positioning and risk statement: Upstream is a single agency (CodeTech, Portugal) with 0 stars and 0 dependents, currently at v3.2.0 with CI across PHP 8.2–8.4 × Laravel 11–13. Recommend adopting behind a pinned constraint with the expectation that we can vendor the code if needed. Do not adopt as a compliance control without a Security review of the redaction denylist against our own schemas.