Steamid Laravel Package

Product Decisions This Supports

• Account identity modeling for gaming products. Any Laravel app where Steam users are first-class citizens (gaming communities, esports/tournament platforms, skin marketplaces, stat trackers, server browsers, clan/team tools) faces a recurring decision: what is the canonical user identifier, and how do we accept the mess of formats users paste in? This package answers it — normalize everything to SteamID64 at the boundary and store that. That is a schema decision, not just a helper function.
• "Sign in through Steam" onboarding flows. Steam OpenID returns a SteamID64. Players, however, bring STEAM_0:1:12345, [U:1:12345], or a steamcommunity.com/id/customname URL from forums, Discord, spreadsheets, and support tickets. This library is the parsing/normalization layer that turns support-ticket-style input into a joinable key — directly reducing manual account-linking work for ops and support.
• Feature scope: player profiles and lookups. Profile rendering, "find your friends," leaderboards, match history, and roster imports all need ID format conversion and profile-link generation. This is a cheap enabler for those features; it should be scoped as plumbing, not as a roadmap item in itself.
• Build vs. buy: buy (with a seam). The conversion math is well-documented and a competent engineer could reimplement it in an afternoon. The real value is the edge cases — vanity URL resolution, legacy Steam2 quirks, input validation — which are tedious and easy to get subtly wrong. At MIT license and near-zero footprint, the build cost is almost certainly higher than the acquisition cost. The decision to make is not "build or buy" but "how tightly do we couple to it."
• Integration/partner roadmap signals. If the product direction includes cross-platform gamer identity (Steam + Discord + Xbox + PSN), deciding now to keep Steam-specific parsing behind an internal SteamIdentity value object or a Laravel cast means later providers slot in without a refactor. This package is appropriate precisely because it is small enough to hide behind that interface.
• Vendor/maintenance risk posture. 174 stars, zero dependents, single maintainer. That is acceptable for a stateless parser with a stable spec, but it is a decision the PM should make explicitly rather than let a developer add silently — the blast radius of this dependency disappearing is a few hundred lines of code, not an outage. Rate it low-risk, low-ceremony: no security review gate needed, but it should appear in the dependency inventory.
• What it does not decide. It is not authentication (no OpenID flow), not a Steam Web API client, not inventory/market/achievement data. If a stakeholder hears "Steam integration," clarify that this covers identity parsing only.

When to Consider This Package

Consider it when:

• The stack is PHP/Laravel and Steam users are a meaningful share of your user base — not a one-off import.
• You accept user-supplied Steam identifiers from any source: pasted profile URLs, legacy forum signatures, third-party tournament spreadsheets, Discord bots, or migration from a legacy database with mixed ID formats.
• You need vanity URL (/id/customname) resolution. This is the one genuinely non-trivial capability; it requires a Steam Web API key and introduces network I/O, so it must be cached and queued — design for that before adopting.
• You want to store a single canonical key and convert to display formats (Steam2/Steam3/profile links) at render time.
• You want a maintainer with domain credibility — xPaw is a well-known figure in the Steam data/community tooling space, which is a stronger signal here than the star count.

Look elsewhere (or write ~100 lines in-house) when:

• You are not on PHP, or you are on PHP but not Laravel and want framework-native validation/casts — the wrapper work is trivial either way, so this is a weak objection.
• Your only ingestion path is Steam OpenID, which already hands you a SteamID64. In that case you do not need parsing at all; a regex and an unsignedBigInteger column suffice. Adopting a dependency you don't exercise is pure inventory cost.
• You need authentication, session handling, or "Sign in with Steam" — use a dedicated OpenID/Socialite provider. This package will not do it, and misreading the scope is the most likely failure mode.
• You need inventory, market prices, friends lists, bans, or achievements — this is not a Steam Web API client; budget for a separate integration.
• You are operating at a scale or compliance level where every third-party dependency requires an SLA, security review, or vendor support contract. A single-maintainer, 174-star library will not clear that bar, and the functionality is too small to justify the exception.
• Vanity URL resolution is a core, high-volume path. The library performs the lookup; it does not solve rate limiting, caching, or the Steam API key lifecycle. If that's central to your product, own that layer explicitly.

Practical guardrails if adopted: wrap it behind an internal service or value object, pin the version in composer.json, and add a contract test over the ID formats you actually accept. That converts a 174-star dependency into a swap-able detail.

How to Pitch It (Stakeholders)

For executives (30 seconds): We need to identify Steam players consistently across our product. Steam has four different ID formats and users paste in whichever one they have, plus profile URLs. This is a small, free (MIT-licensed), actively maintained PHP library that normalizes all of them into one canonical ID in a few lines of code. Cost is effectively zero; it replaces roughly a day or two of engineering plus an ongoing tail of "why doesn't this profile link work" bugs. Risk is low: no database, no network calls except optional vanity-URL lookups, and if it ever disappears we can replace it in a day. Recommendation: adopt, contained behind our own interface.

For engineering (the honest version):

• Scope is strictly identity parsing and format conversion: SteamID64 ↔ Steam2 ↔ Steam3, validation, profile link rendering, optional vanity URL resolution. No auth, no Web API wrapper, no inventory.
• Small surface area, MIT, released as recently as May 2025, maintained by xPaw (credible in the Steam tooling space). Weak points: 174 stars, no listed dependents — treat community validation as thin and rely on our own tests.
• Integration: introduce a SteamIdentity value object or Eloquent cast, store steam_id64 as an unsigned bigint (it exceeds 32-bit and can exceed JS safe-integer range — do not send it to the frontend as a JSON number), and keep the third-party class out of our domain code.
• Vanity URL resolution does network I/O against Steam's API with an API key: wrap it in a queued job with caching and a timeout, and never call it in a request path. Design the fallback (store the raw input, resolve asynchronously) before shipping.
• Add a contract test covering the input formats we actually accept, so replacing the library later is a mechanical change rather than an investigation.