Webex Laravel Package

Getting Started

• composer require laravel-notification-channels/webex — take the v2.x line on Laravel 11. The 2.0 bump is almost entirely a dependency alignment (illuminate ^11), so if you're still on Laravel 10 or below, pin ^1.0 until you upgrade.
• There is nothing to register: no service provider entry, no publishable config required. Laravel's package discovery picks up the channel. The Webex bot token is supplied per-message (or read from a config key you add yourself), not by a global install step — check the README for the exact services.webex snippet before inventing one.
• First use case: post to a Webex space when something happens — a deploy completed, an exception fired, a form was submitted. php artisan make:notification DeployFinished, add the channel class to via(), return a WebexMessage from toWebex().
• Recipient resolution follows the standard channel convention: implement routeNotificationForWebex() on the notifiable to return a Webex person email or a room ID, or address it directly on the message with ->to(...). For one-off sends, use Notification::route(WebexChannel::class, $roomId)->notify(...) — confirm the channel key the package registers against your installed version.

Implementation Patterns

• Fluent message object. WebexMessage::create()->text('...') for plain output, markdown methods for anything with a link, bold, or code block. Plain text renders literally — a raw URL in text is not clickable, so default to markdown for anything operational.
• Generic alert notification over one-class-per-event. For small teams, a single WebexAlert notification taking (string $title, string $body, string $level = 'info') in the constructor beats fifteen near-identical notification classes. Swap to dedicated classes only when the payload shape genuinely differs.
• Centralise the token. Put the bot token in config/services.php behind an env var and read it inside toWebex(). Don't repeat it in every notification, and don't store it as a public property on a queued notification — it will be serialized into the jobs table.
• Queue it. Implement ShouldQueue. Without it, a slow or cold Webex API call adds its full latency to the user's request, and a Webex outage becomes a 500 in your app. Set $tries and $backoff so a transient 429 doesn't silently drop the alert.
• Fan-out. For multiple spaces, return an array from the route method, or loop Notification::route(...) — but be aware N spaces means N HTTP calls; batch into one message with multiple mentions where the content is the same.
• Laravel 11 note. Notifications are unchanged, but the trimmed skeleton removed app/Console/Kernel.php. If you're migrating scheduled Webex digests, move them to routes/console.php / the Schedule facade and verify they still fire before you retire the old deploy.

Gotchas and Tips

• Verify constraints before upgrading. A major version for "Laravel 11 support" usually means Laravel ≤10 was dropped. Run composer why-not laravel-notification-channels/webex 2.* on each app, and don't blanket-update a monorepo where one service is still on L10.
• A 401 is usually not a bad token. It's a bot that isn't a member of the target space, or a token from a different org. The bot must be explicitly added to the room before it can post to it.
• Room IDs are long base64-ish strings and are frequently mangled when copied out of a Webex URL (URL-encoded, truncated). Send one real message from tinker with the ID before wiring it into a notification class.
• Silent no-ops. If nothing arrives and nothing throws, check that the channel is actually in via() and that routeNotificationForWebex() returns non-null — temporarily Log::info() the return value. Missing routes can be skipped rather than raised.
• Testing two layers. Notification::fake() plus assertSentTo($user, WebexChannel::class, fn ($n, $message) => ...) covers your notification wiring. Http::fake(['webexapis.com/*' => Http::response([], 200)]) covers the payload. Assert against $message->toArray() rather than individual getters — accessor names shift between majors, and the array is the stable surface.
• Extension points are thin by design. The package wraps /v1/messages; if you need adaptive cards, threading, or attachment uploads it likely won't expose them. Build the payload yourself with Http::withToken($token)->post('https://webexapis.com/v1/messages', [...]) from inside a notification rather than forking the channel — you keep the notification pipeline and still get the API surface.