Api Client Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy on listing data ingestion (NZ market): Informs whether to source property listings from realestate.co.nz via their first-party client rather than building scrapers or negotiating bespoke feeds.
• Feature scoping: Enables listing search, detail, and syndication-style features for NZ-facing products (agency sites, portals, valuation/AVM tools, market analytics) — but only to the extent the upstream API exposes them. The bundle itself adds no capability, just Symfony service wiring.
• Roadmap sequencing: Because integration cost is mostly configuration (DI/service container), the decision hinges on API access and commercial terms, not engineering effort. Treat "do we have credentials and a data license?" as the gating milestone, not "do we adopt this bundle?"
• Architecture / vendor coupling: Forces a decision about whether to couple directly to a portal's SDK or wrap it behind an internal interface — relevant if you expect to add Trade Me, REINZ, or agency-direct feeds later.
• Ecosystem fit check: Flags the Symfony-vs-Laravel mismatch early, which changes the estimate (Laravel teams would use the underlying api-client package directly with a service provider rather than this bundle).

When to Consider This Package

Consider it when all of the following hold:

• You are building on Symfony (this is a Symfony bundle, not Laravel).
• You have — or are actively negotiating — approved API credentials with realestate.co.nz; without access, the package is inert.
• You want the vendor's own wiring and prefer first-party glue over an in-house adapter.
• Your maintenance policy tolerates a low-signal dependency (0 stars, 0 dependents, no visible release cadence).

Look elsewhere or roll your own when:

• You're on Laravel — use the upstream API client and bind it in a service provider; this bundle won't help.
• You need a multi-portal abstraction; a thin in-house adapter you control is a better long-term seam.
• You lack API access or the commercial terms are unresolved — this is the real blocker, not the code.
• Your dependency policy rejects packages with no adoption evidence; a wrapper of this size is typically under a day of engineering to replicate and own.

How to Pitch It (Stakeholders)

Executives: This is a small, first-party integration shim published by realestate.co.nz for Symfony applications. Its value is convenience, not capability — it saves configuration effort, not product risk. The strategic dependency is API access and data licensing with the portal, so any roadmap commitment should be gated on commercial terms, not on adopting this package. It carries low community signal (no stars, no dependents), so we should not build assumptions on its longevity.

Engineering: If we're on Symfony, adopt it as a pinned dependency and isolate it behind our own interface so we can swap to direct client usage or another source later. If we're on Laravel, skip the bundle and use the underlying api-client package directly. Either way, budget the real work around authentication, rate limits, data mapping, and caching — not around the bundle integration.

Recommendation: Treat as a low-cost accelerator, validate API access first, and keep it behind an internal boundary.