Symfony Laravel Package

Product Decisions This Supports

• Build vs. buy for customer-impact observability. The alternative isn't "nothing" — it's (a) a generic APM (Datadog, Sentry, New Relic) plus custom tagging, or (b) months of in-house work building request instrumentation, a buffered delivery pipeline, customer/tenant joins, and a UI. This package is a narrow, single-purpose buy: normalized endpoint metrics + customer identity, already wired into Symfony's request lifecycle and Messenger. The decision it unlocks is "buy the customer-attribution layer, don't build it."
• Support and escalation workflow — the real product lever. Today, "billing-api is erroring" costs an engineer time to translate into "which customers, on what plan, since which release." The package's core value is that translation: CustomerResolver attaches account id/name/plan, release and environment tags attach the deploy, ApplicationResolver attaches the specific integration/API client. That's the difference between a 40-minute triage and a 4-minute one, and it changes what you can promise in an SLA.
• Incident comms and release gates. Because events carry release identifiers, errors and latency regressions become attributable to a deploy and to the accounts affected. This supports a product decision most teams defer forever: gating rollout by "did this release hurt any named customer?" rather than "is the error rate up globally?"
• Prioritization input for engineering. The allow-listed metadata_keys (e.g. integration_type, region) plus plan on the customer object give you sliced views — enterprise vs. self-serve, region, integration type. That's a legitimate input to backlog ordering and to post-incident review, and it lets you justify not dropping a bug because it "only" affects three accounts.
• Privacy/legal scope decision. The README is unusually explicit: no request or response bodies, credentials, cookies, query strings, IP addresses, or personal data; route templates instead of concrete URLs (/api/invoices/{invoice}); header capture must be opt-in and allow-listed. That materially shrinks the DPIA / DPA / security-review surface compared to a full APM agent, and it's a decision a PM can defend to legal without a new data-processing negotiation.
• Roadmap positioning: not a platform upgrade blocker. PHP 8.2–8.4 and Symfony 6.4 / 7.4 / 8.x coverage means adoption doesn't force a runtime or framework jump. Flag: the release notes claim PHP 8.2–8.5 while the README claims 8.2–8.4 — treat the upper bound as unverified and don't let this dependency sit on the critical path of a PHP 8.5 migration until you've confirmed it in CI.
• Framework reality check. This is the Symfony bundle; it depends on apirelio/php-core, so a Laravel path likely exists but is not what's described here. If the product is Laravel, treat this as evidence the vendor covers PHP, not as the artifact you'd install.

When to Consider This Package

Adopt (pilot) when:

• You run a B2B/multi-tenant API on Symfony 6.4 / 7.4 / 8.x, PHP 8.2–8.4, where the customer account is resolvable at request time (an api_client attribute, an auth token → tenant, a subdomain).
• Your support team currently receives "your API is down/slow" tickets and your engineers cannot answer which release and which accounts without manual digging.
• You already have, or can cheaply add, resolvers — if the request has no stable customer identity, this package has nothing to attribute and its whole value proposition collapses.
• Privacy/compliance review is a real gate for you. "No payloads, no PII, no query strings, route templates only" is a genuinely short review compared to adding an APM agent to a regulated API.
• You want a low-blast-radius pilot: ^0.2 pin, one non-critical service, messenger transport with an async worker, APIRELIO_ENABLED=false as the kill switch.

Look elsewhere when:

• You need production-grade vendor confidence today. Zero stars, zero dependents, one package in a young 0.2.x line, README/CHANGELOG only — this is pre-traction. No commercial SLA, no indemnity, no named support contact, no evidence of a maintainer team. A PM betting a customer-facing SLA on a 0-dependency package with no adopters is taking on unquantified key-person and continuity risk.
• You need traces, spans, logs, or full-fidelity debugging. This is normalized metrics with customer context. The deliberate absence of payload capture means it cannot replace APM for root-causing a specific failure — it tells you who and when, not why. Budget for both, or accept it as a complement.
• You already have Datadog/Sentry at scale. If those are already deployed and your team is willing to maintain tenant tagging, this is a redundant third pane of glass; the incremental value is the pre-built customer view, not the data.
• The version story doesn't reconcile for you. The changelog ships 0.1.0 → 0.2.0 → 0.2.1 (including a rename from tracium to apirelio, which is a config/namespace breaking change for any early adopter), while separate release notes claim v1.0.0. Before anything else, confirm which artifact you'd actually install and what the upgrade path from 0.1.x was.
• Data residency, on-prem, or self-hosted-only requirements. Three transports are described (Messenger, sync HTTP, local NDJSON file buffer), but ingestion is a hosted endpoint. file_buffer gives you a local queue, not a local product.
• You need a durable data-export / exit contract. Nothing indicates a supported export or retention policy — vendor lock-in is real once customer-impact history lives only in someone else's dashboard.
• Your dependency policy requires soak time on a new major line or prior adopters. There are none. Put it on a watch list and revisit.

Non-negotiable validation before commitment (PM asks engineering to confirm):

1. Which version is real (0.2.1 vs 1.0.0), and is 0.2.1 covered by the semver promise you're relying on?
2. Is PHP 8.5 actually in CI, or only in release notes?
3. Does the fail-safe guarantee hold under load — resolver, transport, and logger failures are caught at the request boundary per the README, but verify no added p99 latency at timeout_seconds: 2 / connect_timeout_seconds: 0.5.
4. What happens to buffered events on deploy/restart for messenger and file_buffer? Data loss windows matter if you'll cite this in an SLA.
5. Who maintains it, and what's the plan if they stop?

How to Pitch It (Stakeholders)

To executives: We have a recurring, unbudgeted cost: when the API degrades, we cannot immediately say which customers are affected, on what plan, or whether a recent release caused it. That's engineering hours in triage and, worse, it's our largest accounts finding out before we do. This package closes that specific gap — it attaches the customer account, plan, environment and release to every API error and latency signal, without recording any request or response content, credentials, or personal data. The privacy posture is the selling point internally: it keeps the legal review small. The strategic call it supports is buy the attribution layer rather than build it — equivalent in-house work is instrumentation plus a delivery pipeline plus a UI, which we would own forever and which is not a differentiator. Risk is elevated and I want to be direct about it: this is a young, pre-traction package with no visible adopters and no commercial support commitment. So the proposal is a scoped, reversible pilot on one non-critical service behind a feature flag, with a defined success metric (time-to-customer-impact during an incident) and an explicit exit if the maintainer or maturity picture doesn't improve. We are not putting this on the critical path of a platform upgrade.

To engineering: Minimal integration surface and deliberately low blast radius. Composer install, register ApirelioBundle, set five env vars, add apirelio: config with paths: [/api/*], and it works — the subscriber is auto-registered and records main requests using route templates, not concrete URLs. Two optional contracts (CustomerResolver, ApplicationResolver) are where you map your existing request attributes to ApirelioCustomer / ApirelioApplication; wire them as service aliases in services.yaml. For error codes, setErrorCode()/addMetadata() on ApirelioManager overrides JSON error.code and adds allow-listed scalars — anything unlisted is discarded, so there's no accidental PII leak by default. Default transport is messenger: route BufferApirelioEvents to an async transport so network delivery is off the request path; note that ingestion failures throw inside the worker so Messenger's retry and failure-transport policies apply — that's the correct place for them to fail. sync is for local diagnostics only; file_buffer needs apirelio:flush scheduled or low-traffic apps will strand a partial batch. Resolver, transport, and logger failures are caught at the request boundary, so analytics can lose an event but cannot alter a customer response or mask an exception — that's the property that makes this safe to pilot.

What I need from you before we commit: reconcile the version line (CHANGELOG stops at 0.2.1 and includes a tracium → apirelio rename that breaks early configs, while release notes claim v1.0.0); confirm PHP 8.5 and Symfony 8 are genuinely in the CI matrix rather than just declared; measure added p99 latency under realistic load with the given timeouts; and document the event-loss window on deploy for both messenger and file_buffer. Pin ^0.2, run it through the existing CI rather than a new one, ship behind APIRELIO_ENABLED, and treat the success criterion as reduced time-to-identify-affected-customers in your next real incident — not dashboard adoption.