- How do I install atymic/twitter in a Laravel application?
- Run composer require atymic/twitter, then publish the package config so config/twitter.php exists in your app. Add your four Twitter/X API credentials to the config or your .env file, and the Twitter facade becomes available immediately. No migrations, schema changes, or queue workers are required.
- Which Laravel versions does atymic/twitter 3.4.0 support?
- Version 3.4.0 supports Laravel 10, 11, and 12. It drops support for Laravel 8 and 9, so applications on those framework versions are pinned to the 3.3.x line. Always read the illuminate/* constraints in composer.json rather than relying on release notes, since the 3.4.0 changelog is thin.
- What changed in atymic/twitter 3.4.0 and is it a breaking change?
- 3.4.0 is a dependency-baseline release, not a feature release: it adds Laravel 12 and Carbon 3 support and removes Laravel 8 and 9 from the support matrix. For Laravel 10 to 12 projects it is a compatible minor bump, while Laravel 8 and 9 consumers are effectively hard-capped at 3.3.x. Budget time for verifying Carbon behaviour after upgrading rather than for the package itself.
- How do I upgrade atymic/twitter from 3.3.x to 3.4.0?
- On Laravel 10, 11, or 12, a normal composer update atymic/twitter is the intended path, then run your test suite against real Carbon-dependent code paths. If your other dependencies pin Carbon 2, the Carbon 3 support in 3.4.0 may be unsatisfiable until those are bumped. There are no migration notes for this release, so confirm the resolved constraints in composer.json after updating.
- Can I use atymic/twitter on Laravel 8 or 9?
- Yes, but only with the 3.3.x line, which is your hard ceiling on those framework versions. Pin the constraint explicitly as atymic/twitter: 3.3.* so a transitive bump cannot drag you into an unsupported combination. Do not force 3.4.0 with --ignore-platform-reqs, and open a framework upgrade ticket instead.
- Does atymic/twitter 3.4.0 work with Carbon 3?
- Yes, 3.4.0 adds Carbon 3 support, and since the package can return Carbon instances for tweet and user timestamps, that transitivity matters. Carbon 3 brings behavioural and deprecation changes that usually surface as runtime errors rather than install failures. Check whether the package declares Carbon 3 as a floor or as a ^2|^3 range, and confirm no other dependency still pins Carbon 2.
- How does authentication work with atymic/twitter?
- The package ships an OAuth helper supporting both OAuth 1.0a and OAuth 2.0 flows, covering app-only and user-context access. You supply four credentials in config/twitter.php, and the handshake helper handles the token exchange for acting on behalf of a user or a single brand account. The Twitter facade then exposes tweet, user, timeline, and like endpoints for the authenticated context.
- Can atymic/twitter handle Twitter streaming or high-volume data ingestion?
- No. atymic/twitter is a thin, Laravel-idiomatic wrapper around X's REST API, so it suits read and write calls on behalf of users or one brand account. It is a poor fit for heavyweight streaming, bulk ingestion, or anything needing a stable vendor abstraction layer. For those workloads, plan a dedicated ingestion pipeline rather than pushing the package beyond its design.
- Which Twitter/X API version does atymic/twitter target, and are any endpoints retired?
- The package targets Twitter API v2, exposing tweets, users, timelines, likes, and OAuth. Because X retires endpoints and changes access tiers independently of the package, you should audit which wrapped endpoints you actually depend on before committing. Treat upstream platform and pricing changes as a product-level risk that no package release can mitigate.
- Is atymic/twitter actively maintained, and what are the alternatives?
- The 3.4.0 release consists of one dependency PR and one README edit from two first-time contributors, which reads as a maintenance signal rather than a feature roadmap. Merge rights and release cadence over the last 12 months are worth checking before adopting it for a long-lived integration. If you need heavier guarantees, compare standalone Twitter SDKs and official clients, accepting that you lose the framework-native config, DI, and facade ergonomics.