Pushbullet Laravel Package

Getting Started

• Install with Composer: composer require laravel-notification-channels/pushbullet. The service provider is auto-discovered, so there is nothing to register in config/app.php.
• Get a Pushbullet access token from your Pushbullet account settings and expose it via .env:

  PUSHBULLET_ACCESS_TOKEN=your-token
  

  Then wire it into config/services.php:

  'pushbullet' => [
      'access_token' => env('PUSHBULLET_ACCESS_TOKEN'),
  ],
  

• There is no publishable config file and no migrations. The first place to look is src/PushbulletChannel.php and src/PushbulletMessage.php — the README is short, and those two classes define the entire public surface (message builders, routing expectations, and the HTTP call).
• First use case: an out-of-band alert that is not email. Create a notification, return PushbulletChannel::class from via(), implement toPushbullet(), and add routeNotificationForPushbullet() on your notifiable model returning the destination (an account email or a device iden):

  public function via($notifiable) { return [PushbulletChannel::class]; }
  
  public function toPushbullet($notifiable)
  {
      return PushbulletMessage::create()
          ->title('Deploy finished')
          ->body('production @ '.now());
  }
  

  Then trigger it like any other notification: $user->notify(new DeployFinished());

Implementation Patterns

• Treat it as a "second channel" alongside mail/database. The strongest day-to-day pattern is adding PushbulletChannel::class to notifications that already fan out to email or Slack, so push notifications become an additive alert path rather than a replacement.
• Route explicitly per notifiable. Add routeNotificationForPushbullet() to your User model returning a device iden or email — usually stored as a nullable pushbullet_iden column. Return null/empty when the user has not connected a device and check before dispatching, since a missing route typically fails at send time, not at boot.
• Compose messages with the builder. PushbulletMessage::create() with ->title(), ->body(), and ->link() covers the "note" and "link" pushes you'll send 95% of the time. Keep message construction inside toPushbullet(); it maps cleanly to the API payload and keeps notifications testable.
• Queue it. Implement ShouldQueue on notification classes that use this channel. The channel makes a synchronous HTTP call; queueing isolates your request cycle from Pushbullet latency and gives you retry/backoff for free.
• Ops alerting is the sweet spot. Deploy hooks, failed-job listener, error-spike detectors, backup completion — anything where a phone notification beats another email. Pair with Laravel's Event/Schedule system in Kernel or a listener rather than scattering notify() calls.
• Test with Notification::fake(). Assert with assertSentTo($user, DeployFinished::class). If you need to test the channel itself, wrap the Pushbullet client behind a small interface and bind a fake, or Http::fake() if the channel uses Laravel's HTTP client — this is the only way to exercise payloads without hitting the real API.
• Centralize target logic. If multiple notifications go to Pushbullet, put a notifyViaPushbullet() helper or a dedicated PushbulletAlert notification on the notifiable so the routing rule (device iden vs. email, opt-out flag) lives in one place.

Gotchas and Tips

• Maintenance risk is real. 14 stars, no dependents, last release June 2022. Before adopting, verify the composer.json constraints against your Laravel/PHP/Guzzle versions and run the existing tests. If it won't install cleanly, plan to fork or vendor the two source files.
• Config key mismatch is the #1 failure. The token must live at exactly services.pushbullet.access_token. A missing token usually manifests as an API error at send time, not a boot error — so cache-clear and sanity-check config('services.pushbullet.access_token') first when pushes silently fail.
• Routing shape matters. Pushbullet's push endpoint distinguishes email, device_iden, channel_tag, and client_iden. Whatever routeNotificationForPushbullet() returns must map to the parameter the package sends; returning a full user object or an array of identifiers will produce a 400. Return a single string identifier.
• Free-tier limits. Pushbullet's free plan caps pushes per month and enforces rate limits. A chatty alert (every failed job) will exhaust it fast — throttle at the notification layer or batch into a digest before sending.
• Error handling is thin. The channel generally lets HTTP exceptions bubble up. On queued notifications this becomes retries; on synchronous sends it becomes a 500. Either queue everything or wrap notify() in a try/catch where a missed alert shouldn't break the request.
• Feature coverage is partial. File uploads, SMS, encrypted pushes, and Pushbullet "channels" are not exposed. For those, use the official Pushbullet PHP client or raw HTTP calls in a custom channel rather than fighting this one.
• Debugging: intercept the payload by dumping PushbulletMessage before dispatch, and enable Guzzle/Laravel HTTP logging on the channel to see the actual request body and API response. The response body from Pushbullet is descriptive enough to pinpoint identifier vs. token vs. quota problems.
• Extension points: subclass PushbulletChannel to add logging, retries, or metrics, and subclass PushbulletMessage to add a builder method for a payload field the package doesn't expose. Keep the subclassed channel registered via via() so nothing else changes.
• Always have a fallback. Given the package's age and Pushbullet's account-level dependency, route alerts to at least one other channel (mail or database) so a token revocation or package breakage doesn't take your only notification path offline.