Linked In Notifier Laravel Package

Product Decisions This Supports

• Build vs. buy on outbound LinkedIn delivery. This package buys exactly one thing: the request-shaping and auth plumbing for a single outbound send (roughly 2–3 dev days of work). It buys nothing else — no OAuth onboarding, no product approval, no webhooks/inbound events, no profile reads, no token rotation, no observability. Frame the decision as "do we buy a send button?" not "do we buy a LinkedIn integration?"
• Channel vs. integration roadmap framing. If the roadmap is "announce releases" or "notify a specific member," wrapping this is defensible. If the roadmap includes engagement events, inbound webhooks, or member profile enrichment within 12 months, this package covers a fraction of scope and should not anchor the plan or the estimate.
• Notification architecture. It plugs into symfony/notifier, not Illuminate\Notifications. Laravel does not ship Notifier, so adoption introduces a second, parallel notification abstraction. That is a platform-architecture decision (how many notification spines do we tolerate?) rather than a per-feature toggle — worth an explicit call before the first channel ships.
• Delivery-guarantee / fallback policy. LinkedIn rejections (401/403/429, grant lapses) are inevitable. Product must decide the degradation path — email or in-app fallback, and whether silent non-delivery is acceptable. This decision exists whether or not we adopt the package.
• Vendor-dependency cost modeling. 14 stars, 0 tracked dependents, and "no significant changes" releases spanning 5.4 → 8.1 describe a maintenance-only package with no feature investment. Treat LinkedIn API drift as a recurring internal cost line, not a one-time integration cost. Nobody is absorbing that for us.
• Backlog sequencing. Capability approval sits on the critical path and outside our control, so work should be sequenced behind a product-approval spike rather than behind an engineering estimate. This reorders the backlog regardless of the technical verdict.
• Buy-signal calibration for future packages. Zero dependents means zero Laravel-side prior art, no tutorials, and few searchable failure reports. First-line support becomes internal by default — a useful data point for how we weigh adoption signal in future build-vs-buy calls.

When to Consider This Package

Consider it when all of the following hold:

• The Laravel app already carries Symfony 7.x components, and the requirement is genuinely one-way outbound: publish a post, or notify a specific member.
• A LinkedIn developer app is already approved with the product tier covering our exact use case, and we hold a valid token with a named owner for refresh and re-consent.
• LinkedIn is a secondary channel among several, with modest volume and an acceptable email/in-app fallback.
• We accept owning in-house: a thin adapter, DSN redaction from logs/config cache/exception traces, error mapping into retry semantics, and patching the request shape ourselves when LinkedIn moves.
• The PHP floor fits — pin to the ^7.x line matching the rest of the dependency graph; the 8.x line requires PHP ≥ 8.4.

Look elsewhere when:

• Inbound LinkedIn data (webhooks, challenge handling, engagement events, profile reads) is on the roadmap within 12 months — the package contributes nothing there.
• The use case is member-to-member messaging or arbitrary "notify this user." LinkedIn restricts these heavily and they are unavailable to most third-party apps; no engineering effort creates the grant.
• No approved LinkedIn product exists. This is a hard stop, not a risk to be mitigated.
• The team wants a single notification abstraction. A direct client on Http::withToken() against LinkedIn's versioned REST API costs 5–10 days, gives full control of version headers, retries, and error typing — likely the better long-term trade given the maintenance-only release signal.
• Compliance constraints (data residency, retention of member-derived data) push toward direct API consumption.
• The estate is already pinned to Symfony 8.x elsewhere — mixing sub-package lines risks constraint conflicts; coordinate a Symfony-wide bump first rather than a targeted one.

How to Pitch It (Stakeholders)

To executives: This is not a LinkedIn integration — it is a LinkedIn send button. It is MIT-licensed from the Symfony organization, so provenance is credible, and it replaces roughly 2–3 days of HTTP and auth plumbing for outbound posts only. The full cost is 4–7 dev days to wrap it for Laravel, plus permanent ownership of token rotation and API-drift patching, because the release history is maintenance-only and there is essentially no adoption evidence to lean on. The decisive constraint is not code — it is platform access: without an approved LinkedIn app covering our exact use case, the answer is no regardless of engineering effort. Recommendation: authorize a one-day spike (one live send under our own approved app, plus induced 401 and 429 mapped to typed exceptions, plus confirmation of which API version the transport emits). If the spike succeeds within the grant we hold, wrap it and ship. If it fails or the grant is narrower than the use case requires, fall back to a direct client — 5–10 days, we own everything, and given the vendor signals it is probably the sounder long-term position.

To engineering: Wrap, do not port. The transport is a stateless outbound delivery client with a static DSN factory; it runs without a Symfony kernel, DI container, or FrameworkBundle, so no service-provider bridging is needed. Coupling exists at three seams only: HTTP (needs a PSR-18 / symfony/http-client implementation, not the Http facade), events (pass null to skip the Symfony dispatcher), and async (do not introduce Messenger — run it synchronously inside a normal queued job with $tries = 3 and exponential backoff so the queue owns retries). Expose exactly one Illuminate\Notifications channel plus one container-bound client so no Symfony class leaks into the codebase and the swap option stays open. Pin symfony/notifier and the bridge together on ^7.x, verify with composer update --dry-run, and store the token in a secrets manager with DSN redaction enforced in exception handlers and config:cache output. Plan on patching this ourselves within a quarter or two.