Whereby Bundle Laravel Package

Getting Started

First, confirm what you actually installed. Enius publishes Symfony bundles; this package is almost certainly a Symfony bundle (*Bundle.php, DependencyInjection/Configuration.php, Resources/config/services.yaml), not a Laravel package. There is no WherebyServiceProvider, no extra.laravel.providers, and php artisan vendor:publish will find nothing. Check composer.json (type, require, extra.symfony) before planning any integration work.

Minimal steps (assuming the Symfony bundle shape):

1. composer require enius/whereby-bundle — expect a platform conflict on PHP 8.x / Symfony 6+ since the last release was 2020-10-26. If it refuses, fork it, loosen require, and vendor it.
2. Read DependencyInjection/Configuration.php — that is the authoritative list of config keys (almost certainly an API key/token, possibly a base URL). Ignore the README if it disagrees.
3. Find the client/service class under src/ (look for Whereby, WherebyClient, WherebyService, or a Client/ directory). This is the only class you want to touch from your app.
4. Set the token from env: WHEREBY_API_KEY=.... If the bundle reads a container parameter, bridge it manually from config('services.whereby.key').
5. If the service class has no container dependencies, just new it in a Laravel service provider. If it does, you'll need to instantiate its dependencies by hand or write a thin adapter.

First use case: create a meeting for a scheduled call and hand back two URLs — roomUrl for attendees, hostRoomUrl for the moderator. That single flow exercises auth, payload shape, and error handling, which is everything this package does.

Implementation Patterns

Never call the bundle's client directly from controllers. Define your own contract and bind it:

interface VideoRoomProvider {
    public function create(CarbonInterface $startsAt, CarbonInterface $endsAt, string $prefix): VideoRoom;
    public function delete(string $meetingId): void;
}

Implement it with the Enius client, bind it in AppServiceProvider, and you've isolated a 2020 package with zero dependents behind one seam. When it breaks — and it will — you replace one class.

Persist everything the API returns. A video_rooms table with meeting_id, room_url, host_room_url (encrypted cast), starts_at, ends_at, provider. Room URLs are your only handle on the meeting later; the bundle gives you no local state.

Create rooms lazily, near the start time. Don't pre-provision a room per appointment weeks in advance. Whereby meetings have a fixed startDate/endDate window, and creating them on a queue job 15 minutes before the call keeps the room list clean and limits damage from a wrong payload.

Keep hostRoomUrl out of every serialized response. It's the equivalent of an admin link. Store it encrypted, expose it only through an authenticated endpoint scoped to the meeting owner. Attendees get roomUrl and nothing else.

Send dates in ISO 8601 UTC with a Z suffix. Whereby's API is UTC-only. If the bundle does any formatting, verify it doesn't strip the timezone — a naive Y-m-d\TH:i:s will silently create rooms in the wrong window.

Queue the API call and wrap it in a timeout + retry. Network calls to a third party do not belong in a request cycle that also writes to your DB. Use a job with retry(3), backoff, and a short connect timeout.

Test against your interface, not the package. Http::fake() only helps if the bundle uses Laravel's HTTP client — it won't; it predates it and will be on Guzzle or Symfony HttpClient. Fake VideoRoomProvider in feature tests and write one integration test against the real API behind a separate suite.

Gotchas and Tips

• It's not a Laravel package. No auto-discovery, no config publishing, no facade. Everything is manual glue. Budget for that; it's the single biggest cost here.
• Dependency rot is the real risk. Zero stars, zero dependents, last release 2020. There is no one to file an issue with. Treat the package as a code sample: read src/, copy the HTTP call, delete the dependency. That is often cheaper than fighting the version constraints.
• The API has moved on since 2020. Whereby added roomMode, templateType, hostRoomUrl, and changed response shapes. The bundle's DTOs may drop fields the API now returns, and may send fields the API now rejects. Log raw request/response bodies once during rollout and diff against current Whereby docs before trusting the client.
• DELETE /meetings/{id} deletes the meeting object, not necessarily an in-progress call. Don't build "end call" on top of it.
• Config caching bites. If the bundle reads %env()% inside a container parameter, php artisan config:cache won't help you — it's Symfony's container, not Laravel's. Resolve the key at the point of instantiation instead.
• Debugging: enable Guzzle middleware logging or a Symfony HttpClient logger on the underlying client, and log a correlation ID alongside meetingId. When a room silently fails to appear, the HTTP status is the only evidence you'll have.
• Extension points are thin. There's likely no event dispatcher and no pluggable HTTP layer. The practical extension points are: decorate the service class, or bypass it and call the API yourself with Http::withToken(). Both are legitimate; the second is more honest about what you're maintaining.
• Abandoned-package rule of thumb: if the wrapper is under ~200 lines of HTTP calls, inline it. Given the maturity signals here, assume it is, and verify in five minutes before you commit to a dependency you can't upgrade.