Laravel Steam Api Sdk Laravel Package

Product Decisions This Supports

• Roadmap sequencing for Steam-backed features. The package covers the read surface most consumer-facing Steam features need: player summaries and ban/visibility state, stats and achievements, current player counts, news feeds, group membership, and (new in 0.9.0) Steam's own clock and the list of Web API methods your key is authorized to call. A PM can commit to a "profile cards," "achievements sync," or "live player count" milestone knowing the transport, auth, and throttling layer already exists rather than sitting in an estimate.
• Build vs. buy on the integration layer. The things a team would otherwise rebuild are exactly the things shipping in this release: configurable local rate limiting, queue-aware throttling (RespectsSteamRateLimit releases a job until the budget resets), a fluent fake for tests, and a pluggable HTTP sender. Adopting is defensible on those three or four capabilities alone; writing them in-house is a multi-sprint detour off the roadmap.
• Quota and launch-capacity planning. The hardcoded 100,000/day cap is now steam-api.rate_limit.limits with ['allow' => …, 'every' => …, 'sleep' => …], every accepting seconds or 'day'. That turns "how many Steam calls can feature X afford per user" from a fixed constraint into a tunable, per-environment product decision — strict in production, [] (unmetered) locally so dev work never trips a counter.
• Whether to fan out per-user. Because the budget now resets at 00:00 UTC rather than 24 hours after first request, capacity math is predictable and testable. That makes per-user Steam reads (e.g. refreshing every member of a friends list) a decision you can model rather than guess at.
• Reliability decisions around private profiles. The friends-only fix is product-relevant, not cosmetic: previously a single friends-only profile in a batch of up to 100 threw UnexpectedValueException and failed the entire call. Any feature that renders a list of Steam users was one private account away from a broken page. That class of defect is now gone, and PlayerSummaryFactory::friendsOnly() makes it a first-class test case.
• Observability and APM selection. Steam traffic now appears in Laravel Nightwatch's outgoing requests with the API key stripped from every recorded URL. If Nightwatch is on the table, this is a concrete point in its favor — third-party dependency health lands in the same traces as first-party work — and it clears the security objection that usually blocks instrumenting outbound calls.
• Test strategy and QA cost. WebApiInterfaceFactory, WebApiMethodFactory, WebApiParameterFactory, plus SteamResponse::serverInfo(), supportedApiList(), and supportedApiListInvalidKey() on the fluent fake under ->webApi(). This is the argument for not standing up a cassette/VCR layer: failure modes like an invalid key are now one line in a feature test.
• Egress and infrastructure policy. steam-api.http.sender names a Saloon Sender the container builds on each connector resolution, so a binding decides how requests actually leave. Proxy routing, retry policy, and custom middleware become configuration rather than a fork — an input to any "do we need an egress gateway" conversation.
• Support and on-call ergonomics. php artisan about gains "429 Cool-down," "Sender," and a "Requests Remaining" row enumerating every local limit. First-line support can read quota state without a debugger, which reduces escalations to engineering.
• Key scoping before you commit. supportedApis() reports what your configured key can actually call. Before promising a feature that needs a permission you don't have, this is a five-minute audit rather than a mid-sprint discovery.

When to Consider This Package

Adopt when:

• You're on Laravel and Steam data is a real product surface, not a single one-off lookup.
• Call volume is high enough that local metering and 429 handling are worth owning — particularly if Steam calls originate from queued jobs, where an unthrottled batch can burn a daily budget in minutes.
• You need deterministic tests around third-party HTTP and don't want to maintain your own fixtures.
• You already run Nightwatch, or want outbound requests traced with secrets redacted.
• You want middleware or proxy control over Steam traffic without patching a dependency.

Go in with eyes open:

• Pre-1.0 with real churn. 0.9.0 alone carries four breaking changes: 19 facade endpoint helpers removed in favor of resource-scoped calls (Steam::groups($id) → Steam::users()->groups($id)), sender() no longer a GuzzleSender (so addMiddleware() and getHandlerStack() are gone), an exception renamed, and an about --json key renamed. The migration is mechanical but not free; budget upgrade time per minor and pin the version.
• Published-config trap. Laravel merges only the top level of a package config, so a config file published before 0.9.0 lacks http.sender, rate_limit.limits, and rate_limit.cooldown — STEAM_API_SENDER and STEAM_API_RATE_LIMIT_COOLDOWN go unread until the keys are copied in. Make config republishing an explicit upgrade step, not an assumption.
• One-time counter reset. The daily limit was renamed 100000_every_utc_midnight, so a counter held in a persistent rate-limit store restarts from zero once. Deploy with that in mind so you don't combine it with a backfill and produce a burst.
• Budget window semantics changed. Rolling 24-hour windows became a fixed 00:00 UTC reset. Any capacity model built on the old behavior needs revisiting.

Look elsewhere when:

• You need one or two endpoints, ever. A direct Guzzle call is cheaper than a dependency and an upgrade cadence.
• You're not on Laravel — most of the value here is framework wiring.
• You need Steamworks/partner-scoped APIs, inventory, microtransactions, or leaderboard writes. This is the public Web API surface.
• You require a stable 1.0 contract or a support commitment before you build on it.
• You depend on reaching into the underlying Guzzle client. That escape hatch closed in this release.
• You need Valve's own per-endpoint limits modeled precisely; steam-api.rate_limit is your guardrail, not a mirror of Valve's enforcement.

How to Pitch It (Stakeholders)

For executives: This is the plumbing under every Steam-facing feature on the roadmap — profiles, achievements, player counts, news. Adopting it removes a build item from the critical path and puts a configurable ceiling on third-party spend and failure blast radius, with Steam's traffic now visible in our existing observability stack and API keys scrubbed from what it records. The cost is upgrade churn: the library is pre-1.0 and this release alone carries four breaking changes, so treat each bump as a small scheduled task (roughly a focused half-day for the endpoint migration) rather than a free upgrade. Net: faster delivery on Steam features, contained third-party risk, a known and modest maintenance tax.

For engineering: The 0.9.0 upgrade is mechanical — facade endpoint helpers move onto their resources with identical names, arguments, and return types, so it's a find-and-replace guided by the API reference. Three things are worth actually designing around: middleware moves off sender() onto a GuzzleSender subclass bound in the container and named via STEAM_API_SENDER; rate limiting becomes configuration (limits and cooldown) rather than a fixed 100k/day, which means you choose the policy per environment; and published configs from earlier versions won't pick up the new keys, so republish or hand-merge. Two changes reduce work downstream: the fakes now cover ISteamWebAPIUtil and friends-only summaries, so failure-path tests stop needing hand-rolled HTTP stubbing, and Nightwatch traces Steam calls automatically with keys redacted — no instrumentation to write. Also note the daily-limit rename resets any persistent counter to zero once, so don't pair the deploy with a bulk job.