Foursquare Api Client Laravel Package

Product Decisions This Supports

• Feature feasibility for location-aware surface area: POI/venue search, "near me" discovery, store/partner locator, place autocomplete, venue detail pages (hours, photos, tips), and Foursquare category taxonomy. This is the fastest way to answer "can we ship a location feature this quarter?" before committing engineering time.
• Build vs. buy, correctly framed: this package is a thin HTTP wrapper (config file, service provider, facade, Guzzle underneath) — a few hundred lines. The real buy decision is Foursquare's place data and its terms, not this client. Evaluate the data contract and pricing, then treat the client as disposable glue.
• Data-source selection: gives a cheap comparison point against Google Places, Mapbox, and OSM/Overpass on coverage, category quality, photo/tip richness, per-call cost, attribution requirements, and caching rules.
• Integration effort estimation: forces the team to scope config/credential management, response mapping to domain objects, error and rate-limit handling, and caching — the work that actually dominates a location integration.
• Dependency risk decisions: an abandoned dependency is a roadmap input. This one implies a "wrap it behind our own interface and budget for replacement" decision rather than a "standardize on it" decision.
• Prototype-to-production gating: use it as a spike to validate demand signals (search volume, conversion on venue pages) before funding a durable integration.

When to Consider This Package

Consider it when:

• You're on a legacy Laravel 5.x / PHP 5.6–7.x codebase already depending on it, and the work at hand doesn't touch that path.
• You need a time-boxed spike or internal tool (a few days) to prove a location feature, and Laravel-shaped ergonomics (config file, facade, DI) save real time.
• You will isolate it behind your own gateway/repository interface, so replacing it later is a swap, not a rewrite.
• Your use case maps to Foursquare v2-era endpoints (venues, search, categories, photos, tips) and volume is low enough that hand-rolled retry/caching isn't required.

Look elsewhere when:

• Greenfield or new build. Foursquare's current Places API changed endpoint shape and auth (API key / newer token model); a 2017 client targets the legacy surface. Use Laravel's HTTP client or Saloon directly — comparable effort, and you own it.
• Laravel 9/10/11 with PHP 8.1+. No release since 2017-02-08, 39 stars, single maintainer, no security policy or CVE process. Expect PHP 8 deprecation/type issues, stale Guzzle constraints, and no response to upstream API changes.
• You need social-graph data (check-ins, hereNow, user history) — Foursquare has largely withdrawn these for third parties; don't build a roadmap on them.
• Production scale. You'll need backoff, rate-limit awareness, response caching, typed DTOs, and observability. You will end up rewriting this wrapper.
• Compliance or procurement review requires a maintained dependency with an active maintainer and license/security posture — this package won't clear that bar.

How to Pitch It (Stakeholders)

To executives: "This is a small, free adapter that lets our PHP stack read Foursquare place data. It can compress a discovery sprint from weeks to days, but it hasn't been updated since 2017 and Foursquare's API has moved on since. Treat it as a prototyping tool, not a platform dependency. The material decision isn't this library — it's whether we contract for place data at all, and at what cost per call."

To engineering: "Thin, Laravel-flavored wrapper over Foursquare v2: config file, service provider, facade, Guzzle underneath — roughly the surface we'd write ourselves in a day or two. Zero maintenance since Feb 2017, one maintainer, 39 stars. Recommendation: either skip it and call the current Places API through Laravel's HTTP client, or use it strictly behind our own PlaceRepository interface with a scheduled replacement ticket. Do not let it leak into domain code."

Verdict to record: No for greenfield; conditional, time-boxed yes for a spike — contingent on interface isolation and a named owner for replacement.