- How do I install and register jolicode/slack-php-api in a Laravel application?
- Install it with Composer alongside a PSR-18 HTTP client and PSR-17 request factory, such as Guzzle. Then construct the generated Slack client in a service provider or bootstrap file and bind it as a singleton in Laravel's container. There is no package-specific install command or config publish step.
- Does jolicode/slack-php-api include a Laravel service provider, facade, or config file?
- No. It is a framework-agnostic transport SDK, so it ships no Laravel service provider, facade, config file, migrations, or queue and event integration. You add your own container binding and optional Laravel wrapper if you want those conveniences.
- Which Laravel and PHP versions does jolicode/slack-php-api support?
- The package targets PHP 8.x and works with Laravel 9 through 12 because it relies on PSR-18 and PSR-17 rather than Laravel internals. Check its Composer requirements and your PSR client versions before upgrading, especially if you standardize across multiple Laravel apps. The generated code is tied to Slack's OpenAPI surface, not to a specific Laravel release.
- Can I use Laravel's HTTP client as the PSR-18 implementation for this Slack client?
- Laravel's Http facade is not PSR-18 out of the box, so you cannot pass it directly as the client without an adapter. Use a thin PSR-18 adapter around Laravel's HTTP client to keep logging and HTTP event hooks, or register Guzzle or Symfony HttpClient as the PSR-18 implementation. The adapter approach avoids running a second HTTP stack in the container.
- How do I send a Slack message with chat.postMessage using jolicode/slack-php-api?
- Instantiate the client, resolve the generated chat endpoint, build the postMessage request model with channel and text, and call the endpoint method. Wrap that call in your own SlackGateway class so controllers and jobs do not depend on generated classes directly. Check the exact endpoint and request class names against the installed generated surface.
- Does jolicode/slack-php-api handle Slack rate limits, errors, and Retry-After headers?
- Plan to handle Slack's ok/error envelope in your gateway and HTTP 429 and Retry-After semantics in PSR-18 middleware or the underlying client. The generated models cover Slack response payloads, but you still need application-level error mapping and retry policy. Centralizing this in one adapter prevents every call site from reimplementing rate-limit handling.
- Does jolicode/slack-php-api handle Slack OAuth, Events API, and request signature verification?
- No. This package covers the Slack Web API only. OAuth installation, Events API subscriptions, Socket Mode, and inbound request signature verification are application responsibilities you must build or add through other packages.
- How should I test Slack integrations in Laravel without calling the real Slack API?
- Inject a fake PSR-18 client or mock your own SlackGateway interface so tests never hit Slack. Because the package is transport-level, Laravel's HTTP fake helpers do not automatically cover it unless you adapt Laravel's client. Assert the generated request payloads and your error and retry behavior at the gateway boundary.
- Is jolicode/slack-php-api maintained and safe to standardize on for production?
- It is MIT-licensed and credible for typed Slack Web API calls, but the project has a small-maintainer profile and generated artifacts can change when Slack's spec changes. Treat it as a transport dependency behind an internal interface, pin versions, and review changelogs before regenerating or upgrading. For multiple product surfaces, assign an owner for maintainer communication and upgrade testing.
- How does jolicode/slack-php-api compare with raw Guzzle or slack-php/slack-php-api?
- Compared with raw Guzzle, it gives you typed endpoint methods and request and response models generated from Slack's official OpenAPI spec, at the cost of generated-code churn. Compared with the older slack-php/slack-php-api client, it is the more current generated approach, but neither replaces building your own Laravel integration layer. Raw Guzzle remains an option when you need only a few endpoints and want minimal dependencies.