Weave Code
Saloon Logger Plug In Laravel Package
bit-mx/saloon-logger-plug-in
A Laravel plug-in for the Saloon HTTP client that adds observability to every HTTP interaction. It logs requests, responses and exceptions to a database table, linking them with a single ULID trace_id, and censors sensitive fields in payloads and headers. Enable it by applying traits to your connect...
At a glance
Frequently asked questions about Saloon Logger Plug In
- How do I install and set up bit-mx/saloon-logger-plug-in in a Laravel app?
- Install it with composer require bit-mx/saloon-logger-plug-in, then publish the migration using php artisan vendor:publish --tag=saloon-logger-migrations and run php artisan migrate. Optionally publish the config with php artisan vendor:publish --tag=saloon-logger-config to create config/saloon-logger.php, where you control which fields get censored. After that, apply the HasLogging trait to your connector and the ProvidesDefaultBody trait to requests that should log a default body. The whole setup is a handful of commands plus traits, so it can be rolled out one connector at a time.
- What PHP, Laravel and Saloon versions does saloon-logger-plug-in require?
- The package README pins PHP ^8.2, laravel/framework ^12.39 and saloonphp/saloon ^4.0, while earlier write-ups of the same package cite Laravel ^12.35 and Saloon ^3.0, so always confirm against the composer.json of the version you install. That is a narrow version window: teams still on Saloon v2 or Laravel 11 and below must upgrade the framework and the HTTP client before adopting. If you are mid-upgrade, do the Laravel and Saloon bump first and add this package afterwards.
- How do I enable logging on a Saloon connector and request?
- Add the HasLogging trait to your connector class, which hooks the logger into the Saloon lifecycle for every request sent through it. On requests where you want the outgoing body captured, also use the ProvidesDefaultBody trait and implement the HasDefaultBody contract so defaultBody() is available to the logger. Because it is trait-based, enabling or disabling logging is a per-connector decision that is easy to revert. There is no service provider registration or global switch needed beyond the config file.
- How does the trace_id work and can I correlate logs across services or with my APM?
- Each HTTP interaction gets a ULID trace_id, and the request, response and any exception rows written for that interaction all share it, so you can query a full round trip with a single where clause. It is an application-level identifier, not a W3C traceparent, so it will not automatically join distributed traces in OpenTelemetry, Datadog or Sentry. If you need cross-service correlation you have to propagate the value yourself, for example by sending it as a header and logging it downstream. Treat it as an in-app audit trail rather than a replacement for real distributed tracing.
- How do I censor passwords, tokens and other sensitive fields in logged payloads?
- The package ships sanitizers (JsonSanitizerRequest and JsonSanitizerResponse) plus a published config file where you list the keys to redact, and you can implement the sanitizer contracts for custom logic. Because redaction depends entirely on that chain and your configuration, a missed field means PII or PCI data is written durably into your database. Review the sanitizer coverage for each specific integration, including nested arrays and headers such as Authorization. Get a security or compliance sign-off before pointing it at payment or auth connectors.
- Does a logging or sanitizer failure break the underlying HTTP request?
- This behaviour is not documented, so it has to be verified in staging before production use. The relevant scenarios are a database outage, a failed insert, or a sanitizer that throws while processing an unusual payload. Because the observability path shares fate with your primary database, a hard failure could turn a healthy third-party call into an application error. Write a quick test that points the logger at a broken connection and confirm the Saloon request still resolves.
- Will saloon-logger-plug-in slow down my app or cause write amplification on hot-path connectors?
- Every logged interaction writes multiple rows (request, response, and possibly exception) to the primary database, so it does add latency and write volume on high-RPS connectors. Large payloads make this worse, since bodies are stored in the log table unless you trim them. Mitigate with indexes on trace_id and created_at, a retention policy, and by enabling logging only on high-value integrations such as payments, auth and webhooks. The trait-per-connector model makes that selective rollout straightforward.
- How do I prune old saloon logger records and manage retention?
- Retention is not the package's strong point: the data lives in a dedicated table in your own database, so growth is your responsibility. Check whether the shipped config includes pruning settings, and if not, schedule an artisan command or job that deletes rows older than your retention window, or partition the table by date on high-volume installs. Whatever you choose, size it before go-live, since a busy connector can generate a lot of rows per day. Also confirm the table is included in your backup and restore drills if the audit trail is a compliance requirement.
- Is bit-mx/saloon-logger-plug-in production ready and actively maintained?
- Assess it as a low-signal, single-maintainer package: repository stats show no stars, no dependents and essentially one release note, so there is no evidence of broad production use. That does not mean it is broken, but it does mean you should budget to own it, either by vendoring the code, forking it, or writing a replacement Saloon plugin if the maintainer goes dark. It is a reasonable fit for internal audit needs in a Laravel shop already standardised on Saloon, and a riskier choice on a critical payment path without a fallback plan.
- What are the alternatives if I need distributed tracing or external log storage?
- If you need cross-service tracing, use OpenTelemetry, Sentry or your APM's SDK rather than a database log table, since a per-interaction ULID will not correlate with upstream services. If compliance requires an append-only external store, ship Saloon events to Monolog and forward them to something like Logstash, Datadog or S3 instead of the primary database. For simpler cases, a custom Saloon plugin or Laravel HTTP client event listeners give you the same request/response capture without a new dependency. Choose based on whether you want queryable SQL audit data or a proper observability pipeline.
Weaver
How can I help you explore Laravel packages today?