Weave Code
Laravel Threads Laravel Package
revolution/laravel-threads
A Laravel package for adding threaded conversations to your models, with support for nested replies and message threads out of the box. Useful for building comment systems, discussions, and structured messaging in PHP apps.
At a glance
Frequently asked questions about Laravel Threads
- What does revolution/laravel-threads actually do?
- It is a thin Laravel service-provider wrapper around Meta's Threads Graph API at graph.threads.net, not a general threaded-comment or nested-reply system for your Eloquent models despite the package blurb. The footprint is a service provider, a config file, and a client class that handles OAuth token exchange, profile retrieval, media container creation, and publishing to Threads. It does not touch Eloquent, queues, or the container in any opinionated way. Treat it as an outbound integration adapter that sits at the edge of your domain.
- How do I install revolution/laravel-threads with Composer?
- Install it like any other package with composer require revolution/laravel-threads, then publish the bundled config file with the vendor:publish command so you can supply your Threads app credentials. The service provider is auto-discovered on modern Laravel versions, so no manual registration in config/app.php is needed. Pin an exact version in composer.json rather than using a caret constraint, since the wrapper tracks a fast-moving external API.
- Which Laravel and PHP versions does revolution/laravel-threads support?
- The package assumes a standard Laravel application on PHP 8.x with the framework HTTP client available, which covers most currently maintained Laravel releases. It is a small, non-invasive codebase, so version conflicts are unlikely, but you should still read the require block in its composer.json before committing. Because it is an edge adapter, it has no bearing on your framework upgrade path.
- Does it implement the Threads container-create, status-poll, publish flow?
- Meta's publishing model is asynchronous: you create a media container, poll until its status is FINISHED, then publish it, which is a two-step orchestration rather than a single call. The package exposes container creation and publishing, but you must confirm in the source whether it models the polling step explicitly or leaves it to you. If it only does single-shot calls, plan to write the wait-and-retry loop yourself inside a queued job.
- How are Threads access tokens stored and refreshed by this package?
- Threads long-lived access tokens rotate roughly every 60 days, so refresh and storage are operational concerns you own regardless of which wrapper you pick. The package is likely stateless per request, meaning it accepts a token and does not persist or refresh anything on its own. Audit the token handling end to end before trusting it in production, and store tokens in your own encrypted, access-controlled store.
- Do I need a Meta developer app and app review to use this package?
- Yes. Feasibility gates are external to the package: Meta requires a Threads developer app, app review for the threads_basic and threads_content_publish scopes, and in many cases a Business or verified account for publishing. None of that is handled by Composer or the service provider. Budget time for the review process before your integration spike, because sandbox testing with a test Threads account comes first.
- Can I fake the Threads API in my tests with this package?
- It depends entirely on whether the client uses Laravel's HTTP client or raw cURL and Guzzle directly. If it uses the framework client, you can call Http::fake() and assert on the outgoing requests just like any other integration test. If it bypasses the client, you will need a different mocking strategy. Check whether the package's own test suite fakes HTTP before you assume testability.
- Which Graph API version does revolution/laravel-threads target?
- The Threads API is young and versioned, so a small wrapper can easily pin a Graph version that Meta has since deprecated. Look in the config and client class for a version constant or a configurable version string. If the version is hardcoded and you cannot override it, that alone is a reason to write your own adapter on Laravel's HTTP client.
- Is revolution/laravel-threads safe to use in production and actively maintained?
- The dominant risk is not code quality, it is abandonment: the repository has minimal stars, zero dependents, and no visible production usage, so there is essentially no maintenance constituency. A codebase this small can be audited end to end in about an hour, which offsets much of that risk. The safe pattern is to define your own ThreadsPublisher interface, hide this package behind it, and put publishing calls in a queued job with retry and backoff rather than in a request cycle.
- What are the alternatives to using this package?
- The most credible alternative is writing the integration directly on Laravel's Http client, which is roughly 100 to 150 lines for OAuth exchange, container creation, polling, and publishing. If that effort is competitive with the spike plus adapter work, skip the dependency and keep full control of token refresh, rate-limit headers, and Graph version pinning. Meta's own Graph API documentation is the source of truth either way, and a self-written client removes the bus-factor concern entirely.
Weaver
How can I help you explore Laravel packages today?