Twitch Sdk Laravel Package

Getting Started

This is a generic PHP SDK, not a Laravel package — there is no service provider, facade, or config file to publish. Treat it as an HTTP wrapper you wire into the framework yourself.

1. Require it via Composer directly from the repo (it is archived, so pin a commit rather than tracking a branch):

   composer require ritero/twitch-sdk:"dev-master#<commit-sha>"
   

   If Packagist resolution fails, add a vcs repository entry in composer.json pointing at https://github.com/jofner/Twitch-SDK.
2. Read the README and the top-level SDK class first — everything is driven from a single client object constructed with your Twitch credentials. Check composer.json for the supported PHP version and the Guzzle constraint before assuming it installs on your stack.
3. Register your Twitch app in the Twitch developer console to obtain a Client ID and Client Secret, and store them in .env (TWITCH_CLIENT_ID, TWITCH_CLIENT_SECRET).
4. First use case: a one-off php artisan tinker session that instantiates the client and calls the "get top streams" / "get game" endpoints, so you can see the raw response shape before committing to a wrapper.

Because the package is unmaintained, first verify which Twitch API era it targets — likely the legacy Kraken API rather than Helix. If so, most endpoints will return 410 Gone or 404 against the live API, and you should budget for a rewrite rather than an integration.

Implementation Patterns

Bind it as a singleton. Create a thin service provider that constructs the SDK client from config/services.php credentials and registers it in the container. This keeps the SDK's constructor out of your application code and gives you one place to swap it later.

$this->app->singleton(\Ritero\TwitchSdk\Client::class, fn ($app) => new \Ritero\TwitchSdk\Client(
    config('services.twitch.client_id'),
    config('services.twitch.client_secret'),
));

Wrap it in a repository/service. Never let controllers touch the SDK directly. An App\Services\Twitch\StreamService with methods like topStreams(int $limit) gives you an interface you can reimplement against Helix when this SDK finally breaks.

Cache aggressively. Twitch data is read-heavy and changes slowly relative to request volume. Wrap calls in Cache::remember() with short TTLs (30–120s for live data, hours for game/user metadata). This also shields you from the SDK's lack of built-in rate-limit handling.

Push bulk work to the queue. Any loop over channels/users should be a job, not inline — sequential SDK calls in a request will burn through rate limits (and the package does no throttling for you).

Normalize responses at the boundary. The SDK returns raw decoded arrays/objects. Map them into your own DTOs or Eloquent models immediately so upstream changes only break one class.

Token handling: if the SDK does not manage OAuth app-access-token refresh, add a small TwitchTokenProvider that caches the token in Redis and refreshes before expiry; inject it into your client factory.

Gotchas and Tips

• It is archived and unmaintained. No security patches, no PHP 8.x/Laravel 10+ compatibility guarantees, no Guzzle v7 support. Audit composer.json and lock a working dependency set, or better, plan the Helix migration now.
• The API it targets is almost certainly dead. The Kraken API was sunset; endpoints will fail. Confirm against current Twitch docs before investing integration effort.
• License is NOASSERTION. That means the actual licensing terms are unclear or non-standard. Get legal clarity before shipping in a commercial product — this is a real blocker, not a formality.
• Zero dependents, 14 stars. There is essentially no community to rely on for bug reports or forks. Read the source; don't assume edge cases (pagination, null fields, 204s) are handled.
• No Laravel-specific error handling. SDK exceptions won't map to HttpException — catch and translate them in your service layer so failures degrade gracefully (e.g. cached fallback for a stream list).
• Config quirks: the SDK may expect credentials passed to the constructor in a specific order or as an array. Check the constructor signature rather than guessing from the README.
• Extension points are limited — if it wraps Guzzle directly, you may be able to inject a custom GuzzleHttp\Client for timeout/retry middleware; otherwise you are stuck with default HTTP behavior, which is a common source of hanging requests in production.
• Debugging: log the raw response body and endpoint before mapping; with a dead/legacy API the failure mode is often a confusing array-shape mismatch rather than a clean exception.
• Recommendation: use this only as a stopgap or reference implementation. For anything long-lived, write a small Helix client (a few endpoints behind a Guzzle wrapper, ~200 lines) and keep your repository interface identical so the swap is invisible to the rest of the app.