Weave Code
Hipchat Laravel Package
laravel-notification-channels/hipchat
Laravel notification channel for sending messages to HipChat rooms via webhooks. It integrates with Laravel’s notification system so apps can deliver room alerts from notification classes, making it useful for legacy HipChat integrations.
HipChat Notifications Channel for Laravel
Frequently asked questions about Hipchat
- Does the Laravel HipChat notification channel still work?
- No. HipChat Cloud was discontinued by Atlassian and terminated in February 2019, and HipChat Server/Data Center was end-of-lifed afterward, so the channel has no live API to call. The package's last release was 2018-11-21 and the repository is archived. Any send() ultimately makes an HTTP request to a decommissioned host, so failure is guaranteed rather than occasional.
- Can I install laravel-notification-channels/hipchat on Laravel 10 or Laravel 11?
- It is effectively a non-starter. The package is from the Laravel 5.5–5.8 era and carries constraints on illuminate/support 5.x, guzzlehttp/guzzle 6.x, and PHP 7.x, which will produce Composer resolution conflicts on Laravel 10 or 11. Forcing installation with --ignore-platform-reqs still leaves a channel class that cannot satisfy the current NotificationChannel contract or HTTP client factory. Even if it loaded, the destination service no longer exists.
- What Laravel and PHP versions does this HipChat notification channel support?
- The package targets the Laravel 5.5 through 5.8 era, PHP 7.x, and Guzzle 6. Those constraints are from 2018 and are not compatible with a modern Laravel stack. Treat anything Laravel 9 or newer as out of scope unless you fork and rewrite the transport and dependencies.
- How do I send a HipChat notification in Laravel using this package?
- In the package's intended design you add HipChatChannel::class to the notification's via() method and define a toHipChat() method that returns a HipChatMessage built with fluent setters such as content(), from(), room(), and format(). Laravel's notification layer then calls the channel's send($notifiable, Notification $notification) method and the package makes the outbound HTTP request. That architecture is the correct shape for a chat notification, but with HipChat discontinued the final HTTP call has no working destination. Use the pattern only as a reference for a live transport.
- Is there still a live HipChat API to send messages to?
- No. Atlassian announced HipChat Cloud's discontinuation in July 2018 and terminated the service in February 2019, and HipChat Server/Data Center was subsequently end-of-lifed. There is no supported live API for this package to call. If someone claims a HipChat instance is still running in an estate, confirm whether it is an air-gapped or grandfathered self-hosted deployment before doing any integration work.
- What should I use instead of this package for chat room notifications?
- Replace the destination, not just the package. Use a maintained channel such as laravel-notification-channels/slack or laravel-notification-channels/microsoft-teams, or write a small custom channel around a generic incoming webhook. This keeps Laravel's via() and toX() notification ergonomics and avoids carrying a dead transport. The actual requirement, such as room alerting, on-call paging, or CI status, should determine which live platform you target.
- Can I fork this package and use it as a template for a custom channel?
- Yes, conditionally. The reusable asset is the structure: a channel class implementing send(), a message DTO with fluent setters like content(), from(), room(), and format(), and a NotificationChannel implementation. Copy that shape and repoint the HTTP layer and configuration at a live endpoint rather than trying to preserve the HipChat-specific code. Do not carry over the query-parameter token handling without replacing it with a header or vaulted secret.
- Is laravel-notification-channels/hipchat maintained?
- No. The repository is archived, the last release was 2018-11-21, and the package has zero dependents and very little community signal. There is no issue history or downstream usage to validate behavior against and no maintainer community to absorb fixes. An archived channel for a discontinued service is a terminal state, not a temporarily quiet project.
- What production risks come with using this package?
- The main risks are a dead endpoint, dependency drift, and unmanaged security surface. A 2018-era channel pulls unmaintained transitive dependencies with no CVE triage or patches, and its HipChat v2 API pattern passed auth_token as a query parameter, which is a token-in-URL logging hazard. Forcing it onto a modern Laravel version creates contract and HTTP client incompatibilities rather than a working integration. In production the send path cannot succeed because the destination no longer exists.
- How should I test a Laravel notification channel if I reuse this package's design?
- Do not test against HipChat; there is no live API. If you copy the channel structure, mock or fake the HTTP client and assert that the message DTO contains the expected content, sender, room, and format. Also test that the notification's via() method selects the channel and that send() passes through to your transport with the correct payload. The package's own behavior cannot be meaningfully validated through downstream usage because it has zero dependents and is archived.
Weaver
How can I help you explore Laravel packages today?