Php Pushwoosh Laravel Package

Getting Started

Install with Composer and pin the package because the last release is from 2017:

composer require gomoob/php-pushwoosh

Look first at the package README and the Gomoob\Pushwoosh\Pushwoosh entry point. In practice you need two Pushwoosh values before writing code: the Auth Token and the Application Code from the Pushwoosh control panel.

Minimal first use case — send to a single device token:

use Gomoob\Pushwoosh\Pushwoosh;

$pushwoosh = Pushwoosh::create();

$app = $pushwoosh->createApplication(
    getenv('PUSHWOOSH_AUTH_TOKEN'),
    getenv('PUSHWOOSH_APP_CODE')
);

$app->createMessage('Deploy finished', ['DEVICE_TOKEN']);

Treat that as the smoke test. Once it works, move configuration into config/services.php or your secrets manager and put the call behind a small application service rather than calling the library directly from controllers.

Implementation Patterns

Wrap the library in your own notifier. The package is a thin REST client, so isolate it behind an interface such as PushNotifier with methods like toDevice(), toDevices(), toUser(), and broadcast(). That keeps Pushwoosh concepts out of controllers and makes replacement easier if the abandoned library becomes a problem.

Use request objects for anything non-trivial. The convenience createMessage() helper is fine for a smoke test, but real payloads need content, device lists, platform targeting, custom data, badges, sounds, and scheduling. Build the package’s message request object, populate it, then send through the application instance. This is also easier to unit test.

Centralize one application per app code. A Pushwoosh client can create multiple Application objects. Cache or inject the correct one per tenant/app. Do not reuse an application object across different Pushwoosh app codes.

Queue notifications. Do not call Pushwoosh synchronously during a web request. Dispatch a Laravel job, let the job resolve the notifier, and retry transient failures. Log the Pushwoosh response body, not just the HTTP status.

Chunk device lists. For multi-device sends, split tokens into batches — commonly a few hundred to 1,000 per request — and let the queue handle each batch. This limits blast radius from bad tokens and keeps request sizes predictable.

Prefer Pushwoosh-side targeting for segments. Use tags, filters, or platform conditions in the request instead of loading every user in your application and filtering locally. The REST API is designed for that and it keeps your payloads small.

Inject and mock in tests. Because the package uses Guzzle underneath, use Guzzle’s mock handler or bind a fake PushNotifier in the container. Assert on the request payload your adapter builds, not on live Pushwoosh calls.

Gotchas and Tips

• The package is effectively unmaintained. Last release was 2017. Check PHP 8 compatibility and Guzzle version constraints before adopting it. Use composer why-not gomoob/php-pushwoosh if resolution fails.
• Pushwoosh’s API has evolved. The library targets older REST endpoints. Verify auth, endpoint paths, and response formats against current Pushwoosh documentation; consider a direct Guzzle client if the old wrapper blocks you.
• HTTP 200 does not always mean success. Parse the Pushwoosh response body and check its status fields. Log the raw response for failed sends; Pushwoosh’s message history in the control panel is also useful for debugging.
• Device tokens are platform-specific. Invalid or stale tokens can cause partial failures in a batch. Prune tokens from your own database when Pushwoosh reports them as invalid.
• Silent and data pushes need platform-specific payloads. Android and iOS handle custom data, content-available, sounds, and badges differently. Test on real devices, not just the API response.
• Scheduled sends need explicit time handling. Set the send date deliberately and confirm the timezone semantics. Do not assume the server timezone matches Pushwoosh’s interpretation.
• Keep credentials out of code. Auth tokens belong in environment variables or a secrets manager. Application codes are less sensitive but still environment-specific.
• Abstract before you depend deeply. Given the package age, keep the adapter small and boring. If you later switch to direct HTTP calls or a newer SDK, only the adapter should change.