Linkedin Bundle Laravel Package

Product Decisions This Supports

• Feature scoping: "Sign in with LinkedIn" / social login. Informs whether LinkedIn is worth adding as a third or fourth identity provider alongside Google/Microsoft/email — this bundle is the integration layer that would make that possible inside a Symfony app.
• Onboarding friction reduction. Profile enrichment at signup (name, headline, photo, email, current position) for B2B/professional products where manually typing company and role is a known drop-off point.
• Verified professional identity. Supports decisions about trust signals — e.g. gating recruiter, marketplace, or community features behind a LinkedIn-verified profile.
• Distribution / content features. Enables roadmap items like "share to LinkedIn," company page posting, or referral flows that depend on a LinkedIn API client.
• Build vs. buy. The real buy decision is not this bundle — it is "do we own the OAuth + LinkedIn API surface, or delegate to a library?" This package represents the "delegate" option, and its age is itself the key input to that trade-off.
• Roadmap prioritization of providers. If your ICP is B2B SaaS, recruiting, or professional services, LinkedIn login may rank above Apple/Facebook; if it is consumer, it likely ranks below.
• Legacy migration decision. For teams with this already installed, it forces a "keep, wrap, or replace" call before the next Symfony upgrade.

When to Consider This Package

Consider it only when all of the following are true:

• You are on a legacy Symfony (3.x/4.x) and PHP 7.x codebase that already depends on happyr/linkedin-api-client.
• You need a thin DI/config wrapper — service definitions, bundle config, autowiring — not new API capability.
• Your integration needs are read-only profile fields and you have validated those fields against LinkedIn's current API contract.
• You are explicitly accepting maintenance risk in exchange for not rewriting an existing integration today.

Look elsewhere when:

• You are building this new. The bundle's last release was February 2018. LinkedIn has since moved to API v2 with required versioned headers (LinkedIn-Version), replaced r_liteprofile / r_emailaddress with OpenID Connect (openid profile email), and changed posting to the Posts API with w_member_social / w_organization_social. A 2018 client almost certainly does not speak this.
• Low maturity is disqualifying. 8 stars, 0 dependents, single maintainer, no releases in ~7 years: no security patching, no bus factor, no community triage. Do not put this on a critical auth path.
• You need PHP 8 / Symfony 5+ / Symfony 6+. Assume incompatible until proven otherwise.
• You need token refresh, error handling, or rate-limit behavior that matches current LinkedIn app-review requirements.

Better-fit alternatives: league/oauth2-client (plus a maintained LinkedIn provider) for the auth leg; HWIOAuthBundle or KnpUOAuth2ClientBundle if you want a Symfony-native social login bundle; the LinkedIn REST API directly via Symfony HttpClient for sharing/posting. Keep this package as a reference implementation, not a dependency.

How to Pitch It (Stakeholders)

For executives: LinkedIn login and profile enrichment are credible features for a professional/B2B audience — they reduce signup friction and give us a verified identity signal. But we should not adopt this specific package. It is a seven-year-old Symfony wrapper around a LinkedIn client, with a single maintainer and no dependents, and it predates LinkedIn's current OAuth 2.0 / OpenID Connect and versioned API requirements. Standing it up would cost more in remediation than writing a thin integration ourselves.

Recommendation: treat LinkedIn login as a scoped, opt-in feature, not a platform bet. Build it as a small in-house integration on a maintained OAuth library plus Symfony HttpClient — roughly one to two sprints of engineering, with the larger unknown being LinkedIn's app-review and scope-approval timeline, which we should start in parallel.

For engineering: this bundle is useful only as a reference for how the service wiring was once structured. The underlying client targets deprecated scopes and endpoints; assume the auth and posting flows must be rebuilt against OIDC and the Posts API, including token refresh and LinkedIn-Version headers. Any existing dependency on it should be flagged as a migration item ahead of the next Symfony/PHP upgrade.