Phrets Laravel Package

Product Decisions This Supports

• Build vs. buy the MLS data pipe. PHRETS is the "build the transport layer yourself" option: with MLS-issued RETS credentials you can pull listings, photos, and agent/office metadata directly, avoiding per-record aggregator fees. It is the cheapest path to first-party MLS data for a PHP team — but it is only the pipe. Normalization, dedupe, IDX/display compliance, and freshness SLAs remain your responsibility.
• Market coverage and expansion sequencing. RETS is still the lowest-common-denominator interface across most US MLSs, so a single library unlocks many markets. This lets you roll out MLS-by-MLS based on agent demand instead of waiting on one aggregator's coverage map.
• Feature roadmap unblocked by listing data. Saved searches and alerts, listing detail pages, photo galleries, open-house and sold-history views, agent/office directories, CMA/valuation inputs, and market-stat dashboards all become buildable once ingestion exists. This package is the enabler for a whole cluster of listing-dependent features.
• Data freshness vs. UX trade-off. Polling-based RETS pulls force an explicit refresh cadence (e.g., nightly incremental pulls, hot listings every N minutes). That cadence sets "how stale can a listing look?" — a product decision, not just an infra one.
• Stack and hiring leverage. For a Laravel shop, this keeps a core data pipeline in PHP and avoids introducing a new runtime just for MLS ingestion, shrinking the team's surface area and shortening time-to-first-listing.

When to Consider This Package

Adopt when:

• You are a PHP/Laravel team with (or able to obtain) direct RETS access to one or more MLSs.
• You need the core RETS operations — login/session, search, metadata, and object/photo retrieval — and can tolerate the protocol's rough edges (server-specific quirks, timeouts, non-standard fields).
• You are willing to own the surrounding layers: scheduling, retries, caching, normalization, and compliance.
• You want a low-cost bridge while a long-term data strategy is decided.

Look elsewhere when:

• Your MLS is on (or moving to) RESO Web API. RETS is a legacy standard and RESO Web API (OData) is the successor; if the target MLS supports it, prefer it rather than building on a sunsetting protocol.
• You need normalized, multi-MLS, deduped data or managed SLAs. Buy from an aggregator/IDX vendor; this library returns raw per-server data with no normalization.
• You need push/webhook updates or near-real-time sync. RETS is poll-oriented; consider RESO subscriptions or an aggregator's webhooks.
• Maintenance risk is unacceptable. Last release was mid-2023, adoption is modest (~458 stars), and overall health signals are lukewarm. Treat it as "likely to need a fork or in-house patches" and budget accordingly.
• You are not a PHP shop, or you want a fully managed integration.

How to Pitch It (Stakeholders)

To executives: This is the lowest-cost, fastest route to first-party MLS listing data for our PHP stack — MIT-licensed, no per-record fees, and one integration pattern that covers many MLS markets. It accelerates launch of listing-dependent features (search, alerts, photos, agent directories) and de-risks market expansion sequencing. Caveats: it is a transport library, not a data product — we still own normalization, compliance, and reliability — and RETS is a sunsetting standard, so treat it as a bridge to RESO Web API rather than a permanent foundation. Recommend a time-boxed pilot on one MLS with an explicit migration plan.

To engineering: PHRETS handles RETS sessions, searches, metadata, and photo/object retrieval so we don't hand-roll the protocol. Wrap it behind a service interface, run pulls as queued jobs with retries and caching, and expect MLS-specific quirks. Note the 2023 last release and modest community — plan a fork/vendored-patch path and keep the abstraction thin enough that a RESO Web API backend can be swapped in without touching product code.