Facebook Marketplace Location Search API
Changed onDisambiguate city names into Marketplace hubs — id + lat/lng.
Resolve a city/place query into Facebook Marketplace location hubs with id (Facebook city_page.id — same value marketplace-search listings expose as cityPageId), slug, city/state, and coordinates when available. marketplace-search already accepts a city string with no lat/lng required — use this endpoint when the name is ambiguous (Austin TX vs Austin MN vs Austin IN) or you need id/coordinates before searching. Bare ambiguous cities (Austin, Portland, Springfield) resolve from a local table in typically under 1s; every other query geocodes globally (typically under 2s) instead of a ~28s Facebook hub scrape. id resolves instantly for ~60 major US metros from a baked directory verified against live listing cityPageId values; smaller cities and non-US places return idResolved:false. marketplace-search still accepts those names — it geocodes a US town and snaps to the nearest baked metro rather than guessing a vanity slug. Envelope timings{path,hubMs,hubCount,geocodeMs,totalMs} including on 504/404. Flat 2 credits.
Docs: https://captapi.com/apis/facebook-marketplace-location-search
Request
- Base URL: https://api.captapi.com
- URL: https://api.captapi.com/v1/facebook/marketplace-location-search
- Auth: one of:
- HTTP bearer
- API key in header X-API-Key
Query parameters
City/place query. Bare names like 'Austin' may return multiple candidates (TX/MN/IN); include a state for a single hit (e.g. 'Austin, TX').
Max items to return (default 10, max 50). Flat 2 credits per call.
Set true to serve from the 24h response cache (0 credits on hit). Default false — always fetch fresh.
Response
Success. The data object for this endpoint.
Changes
- breaking
the response property
///became nullable for the status - warning
removed the optional property
///from the response with the status - info
added the optional property
///to the response with the status
- breaking