Shopping Merchant Datasources Laravel Package

Product Decisions This Supports

• Catalog-to-Google-Channel automation. This package is the control plane for Google Merchant Center data sources — creating, listing, updating, and deleting the primary feeds, supplemental feeds, API data sources, local/regional inventory sources, promotion sources, and product-review sources that feed Shopping ads and free listings. Any roadmap item of the form "get our catalog into Google Shopping without a human touching a spreadsheet" starts here.
• Build vs. buy on feed management. Feed-management SaaS (Channable, DataFeedWatch, Feedonomics, GoDataFeed) typically charges per SKU, per channel, or per feed. This package is free, Apache-2.0, and lives inside the existing Laravel codebase. That makes "build the sync ourselves" financially defensible for a mid-size catalog, and it makes the SaaS buy decision a question of operational toil (error handling, category mapping, disapprovals) rather than technical feasibility.
• Multi-account / multi-market architecture. Merchant Center supports multiple accounts and country/language-targeted data sources. This library makes "one merchant account per region" or "per-brand sub-accounts" a configuration decision rather than a rewrite — worth settling before you build the sync, not after.
• Scope discipline on the integration. This package covers data sources only. Pushing actual products, prices, and inventory is a sibling library (google/shopping-merchant-products, -inventories, -promotions). If someone scopes "Google Shopping integration" as a single ticket, this repo is the tell that it is at minimum three client libraries plus a mapping layer plus a job pipeline.
• Opportunity signal, not adoption proof. The scoring here (opportunity 64, adoption 2 stars / 0 dependents) is characteristic of Google's generated PHP clients: near-zero community gravity, but a maintained upstream spec. Read it as "whitespace in the PHP ecosystem" — if the team ships a clean Laravel Merchant Center package internally, it is a credible open-source differentiator later.
• Roadmap sequencing input. Data-source provisioning is a prerequisite for everything else (product ingestion, local inventory, promotions). It is also the least visible work. Budget it as infrastructure, not as a shippable feature, or it will lose every prioritization fight to customer-facing asks.

When to Consider This Package

Adopt when:

• The product is PHP/Laravel and the catalog already lives in your own database — you want Merchant Center to be a downstream sink, not a source of truth.
• You need programmatic data-source lifecycle: creating a source per merchant/brand/region at onboarding, rotating feeds, or uploading via API data sources where file-based feeds are too slow or too coarse (near-real-time price/availability, per-item updates).
• You need multi-tenant behavior — many merchant accounts, each needing its own sources — which rules out manual Merchant Center UI setup as an operating model.
• You accept vendor-coupling to Google's generated client: authentication via Application Default Credentials or a service-account JSON key, 0.x versioning (pin exact versions in composer.json), and no commercial support beyond the GitHub issue tracker.
• You are prepared to write the orchestration layer yourself — idempotent sync jobs, retry/backoff on quota errors, mapping tables from internal taxonomy to Google's product taxonomy, and a disapproval/error feedback loop.

Look elsewhere when:

• A scheduled feed is sufficient. If daily TSV/XML over SFTP or a fetched URL meets freshness needs, generate the file and skip the API entirely. This is the correct answer for most small and mid-size catalogs and is meaningfully less work.
• You only need product/inventory pushes — this repo does not do that. Reach for the sibling Merchant API clients, or the legacy Content API for Shopping if you are maintaining an existing integration (mind the deprecation path).
• You are not on PHP, or you want a managed feed platform because category mapping and disapproval triage are the actual cost centers, not the API call.
• You need contractual SLAs, support, or guaranteed non-breaking upgrades. Generated Google clients churn; 2 stars and 0 dependents means no community safety net when they do.
• You need promotions, reviews, or local inventory on day one and the team is one engineer — the integration surface multiplies quickly and a feed vendor is cheaper than the quarter of engineering time.

How to Pitch It (Stakeholders)

To executives: This is a free, Google-published PHP client that lets our Laravel platform provision and manage Google Merchant Center data sources directly — the plumbing behind Shopping ads and free listings. It removes a per-SKU SaaS line item and keeps our catalog data inside our own systems. Two honest caveats: it is auto-generated client code with essentially no community ecosystem (2 stars, zero dependents), so it is a dependency we own and monitor, not a supported product; and it covers data-source management only — the product, pricing, and inventory pushes are separate libraries plus work we do ourselves. Recommendation: approve as an enabling dependency for the Shopping channel workstream, sized as internal infrastructure rather than a feature.

To engineering: Composer-installable, Apache-2.0, generated from Google's discovery spec — treat it as a thin transport layer and wrap it. Pin exact versions (0.x releases), authenticate with a service account or ADC, and put every call behind a queued job with idempotency keys, exponential backoff on quota errors, and structured logging of per-item Google errors. Assume you will need to swap or vendor it. Do not let DataSource objects leak into the domain model — map to our own catalog entities and keep the Google-specific shape at the adapter boundary. Pair it with the shopping-merchant-products and -inventories clients so the ingestion path is designed once, not three times.