Uberall Bundle Laravel Package

Product Decisions This Supports

• Vendor vs. build for local listings management. The real product decision is Uberall (the commercial local-marketing platform covering Google Business Profile, Apple Maps, Facebook, Yelp, and others) versus integrating each directory ourselves. This package does not change that call — it is only a transport layer to the buy side. What it does inform is the marginal cost of the buy side: a day or two of glue code, not a sprint. Do not let a 1-star wrapper anchor a six-figure vendor decision.

• Roadmap scoping and effort-to-first-sync. If Uberall is already contracted and credentialed, this bundle gives an early read on what "integration" actually entails: location CRUD, listing distribution, review ingestion, insights. Use it to size the work item (roughly one engineer-week for a production-ready client with jobs, tests, and observability), not to justify the initiative.

• System-of-record and data-ownership strategy. Whether Uberall becomes the canonical store for location data or a downstream sync target from our own database is an architecture decision with long-term migration consequences. It must be settled before any client code is written, and it dwarfs any consideration of this package.

• Build vs. adapt vs. fork. With 1 star, 0 dependents, a single maintainer, and a composite score of 0.205 (opportunity 14.89), this is effectively sample code. The PM framing is: "do we adopt, fork-and-own, or crib the API shape and write our own?" For most teams the answer is the last one — treat it as a reference implementation of the Uberall API surface, not a dependency.

• Platform/framework fit — validate first. Despite being presented as a Laravel/PHP package, this is a Symfony bundle. Laravel has no bundle loader or Symfony Kernel; it consumes individual Symfony components, not framework-bundle extensions. In a Laravel codebase the bundle's DI wiring, services.yaml, and parameter-bag config have no analogue. This mismatch can silently invalidate the entire "cheap integration" premise, so it belongs in the first hour of evaluation, not the last.

• Make-vs-buy on internal ownership. Low adoption signals mean no community safety net, no security disclosure path, and bus factor of one. That is a staffing and ownership decision as much as a technical one: adopting this means budgeting for a fork under internals/ and the maintenance that comes with it.

When to Consider This Package

Consider it when:

• The codebase is Symfony, not Laravel — the bundle's service definitions, autowiring, and environment-aware configuration actually pay off there.
• Uberall is already purchased and credentialed, so the integration is a foregone conclusion and the only question is how much glue code to write.
• You want a reference implementation of the Uberall API surface — auth flow, endpoint paths, payload shapes, directory-specific quirks — to copy from rather than depend on.
• You are prepared to vendor or fork it, accept maintenance ownership, and track Uberall API version changes yourself.
• You need a fast, throwaway spike to enumerate what the API exposes before committing to a build.

Look elsewhere when:

• You are on Laravel. A thin UberallClient over Laravel's Http facade — with retry(), Http::pool, and Http::fake() testability — will be faster to build, easier to test, and cheaper to own than adapting a Symfony bundle. Estimated two days versus roughly a week.
• You need a supported, battle-tested SDK or a vendor-backed integration. One star, zero dependents, and no commercial backing mean no SLA and no escalation channel beyond Uberall's own API support.
• You are not on Uberall. Evaluate the Google Business Profile API directly or alternatives first; this package only makes sense inside that specific vendor commitment.
• You have compliance, audit, or uptime requirements for a customer-facing sync that demand a runbook, on-call owner, and a vendor-supported path.
• You need feature depth beyond basic location calls — reviews, insights, batch workflows, or advanced listing operations may exceed what a low-traffic wrapper exposes.

How to Pitch It (Stakeholders)

To executives: Uberall is a commercial local-listings platform; this is a small, community-maintained wrapper that trims the glue code for talking to it. It unlocks no new capability — the vendor contract does. Adoption signals are weak (1 star, zero dependents, single maintainer, recent but isolated January 2025 release), so treat it as reference code, budget for forking and owning it internally, and do not present it as infrastructure. The build-vs-buy decision sits with the Uberall contract, not this package. The honest framing: it saves a day or two of engineering, and a Laravel team can exceed it in roughly the same time with a native client they fully control.

To engineering: MIT-licensed Symfony bundle, not a Laravel package — the framework mismatch is the first thing to validate, because there is no composer require → artisan path here. Recommended approach: read its services.yaml and DI extension to enumerate the Uberall endpoints, auth model, and payloads, then implement an App\Services\Uberall\UberallClient against our own Http client and config conventions. Integration effort is dominated by the Uberall contract and data-model work, not by this package. Sequence read-only endpoints (locations, listings, insights) first, then writes behind queued jobs with idempotency keys — Uberall propagates changes to third-party directories, so a bad write is externally visible and slow to unwind. Instrument credential expiry, 429 backoff, partial-sync tracking, and upstream schema drift explicitly; untyped array handling will fail silently. If the bundle encodes non-obvious payload logic, vendor the specific service classes rather than importing the Symfony wiring.