- Is hristonev/sportmonks-client-bundle a Laravel package?
- No. It is a Symfony bundle, so it relies on Symfony bundle registration, service YAML autoloading, and the Bundle lifecycle, none of which exist in Laravel. Laravel consumes Symfony components but not the Symfony framework, so this cannot be installed as a normal Laravel package. Treat it as a reference implementation for wiring a SportMonks client.
- Can I install this SportMonks bundle in Laravel 10 or 11?
- Probably not without dependency conflicts. The last tagged release is from April 2019, which pins Symfony packages to 3.x or 4.x and PHP to 7.x, while Laravel 10 and 11 run on Symfony 6/7 and PHP 8.1+. Composer resolution will likely fail before you ever reach runtime.
- Does this package support the SportMonks API v3?
- No. The bundle is pinned to the older SportMonks v2.0 contract, while SportMonks has moved to v3.0 with a new base URL, restructured include syntax, changed pagination, and a different response envelope. Calls against v3 will return 404s or incompatible payloads rather than clean errors.
- How do I integrate SportMonks into a Laravel app without this bundle?
- Write a SportMonksServiceProvider that binds a singleton client from config/services.php, then put your own DTOs and mappers in front of it. Mirror the bundle's useful option surface: API token, base URI, timeout, default includes, and cache TTL. The anti-corruption layer absorbs upstream field renames in one place instead of across controllers and jobs.
- How do I test a SportMonks integration in Laravel?
- Mock the HTTP client in feature tests and assert that your DTO mappers transform SportMonks v3 payloads correctly. Keep a small set of captured fixture responses for contract tests, and avoid hitting the live API in CI. If you wrap the client behind an interface, you can also fake it in unit tests without any network dependency.
- Is the SportMonks client dependency usable without the Symfony bundle?
- Possibly, but you must evaluate it separately. The bundle's value is mostly dependency injection wiring, while the actual HTTP and API logic lives in a separate client library. Check whether that client ships independently and whether it targets SportMonks v3 before relying on it.
- Does this bundle handle SportMonks rate limiting, retries, or caching?
- No. It delegates those concerns entirely to the caller and performs no response validation of its own. You are responsible for rate limiting, retries, caching, and schema checks. Without validation, SportMonks schema drift surfaces as bad data downstream rather than a failed request.
- What is the risk of using an unmaintained SportMonks client in production?
- The main risk is silent API drift: a renamed score field or restructured localteam and visitor keys can be persisted incorrectly by your own domain objects. Because the package does no response validation, you may not notice until bad data reaches users. There is also a supply-chain risk, since an unmaintained package with an HTTP client dependency has no patch path once it is in composer.json.
- Which SportMonks endpoints should I scope for a Laravel integration?
- Start with the endpoints you actually need, such as fixtures, livescores, leagues, teams, and players. Odds, standings, squads, and predictions significantly expand scope and may justify a different client. Your endpoint list determines whether a thin in-house Guzzle wrapper is better than any third-party client.
- What is the best alternative to this bundle for Laravel?
- Use SportMonks' official PHP client if it covers your required endpoints and include depth, or build a thin Guzzle-based wrapper. Either way, wrap it in a Laravel service provider and your own DTO mapping layer. The Symfony bundle itself is best treated as documentation, not a dependency.