DarakPlatform
Use casesDocsGuidesPricing
DocsGuides
Guides

Start here

  • Quickstart
  • Authentication

AI & MCP

  • Connect an AI assistant
  • Build with Darak and AI

About the data

  • What a listing is
  • Coverage and freshness

Building with it

  • Searching and filtering
  • Webhooks
  • Keeping a copy in sync

Operating

  • Limits and quotas
  • Pagination
  • Retrying safely
  • Errors
  • Versioning

Policies

  • Terms in practice

API reference →

Searching and filtering

GET /listings takes 34 filters. city and listing_type are the only required ones; everything else narrows. GET /listings/count accepts the same 34 and returns just a total, which is how you get one — search itself doesn't return a count.

Values that are lists, ids or slugs come from the reference endpoints rather than from this page, so they can't go stale: GET /cities, GET /cities/{city}/neighborhoods, and GET /enums for property types, amenities, sources and the rest.

GroupFilters
Locationcity, neighborhood_id, neighborhood_id_exclude, bbox, compound, in_compound
Typelisting_type, listing_category, property_type
Priceprice_min, price_max, rent_frequency
Sizearea_min, area_max
Roomsbeds, beds_min, beds_max, bathrooms, bathrooms_min, bathrooms_max, livings_min
Attributesamenities, amenities_exclude, furnished, floor, max_age, verified
Freshnessupdated_since, days_on_market_min, days_on_market_max
Sourcesource, source_exclude, advertiser_type
Textq

Things worth knowing before you rely on them

A few filters don't behave the way their name suggests. None of this is accidental, but none of it is guessable either.

  • beds is exact — at every value. darak.app's own filter treats beds=5 as five-or-more, so the same number returns a different set there. Use beds_min when you want a range. The same applies to bathrooms.
  • q searches what the advertiser wrote, meaning title and description — not headline, which Darak composes for the response. Several words must all appear; "quote a phrase" to match it whole; | between terms for either. Sources that post no title at all (Aqar among them) are matched on description alone.
  • floor=ground and floor=upper don't partition. A listing whose floor the source never stated is in neither.
  • verified=false means "not marked verified", which includes every listing the source said nothing about — not only ones it marked unverified.
  • neighborhood_id_exclude keeps listings Darak couldn't place; neighborhood_id drops them. Excluding three neighborhoods is therefore not the same as including all the others.
  • A misspelled source narrows to nothing. Parameter names are validated, so a typo there is an unknown_parameter error — but source values aren't checked against the list, so source=bayutt quietly returns an empty page. GET /enums has the real ones.
  • Listings with no price never appear in search, even though price.yearly_sar is nullable and a detail lookup can return one.
  • property_type with several values shifts the quality bounds. The outlier filter calibrates per property type only when you ask for exactly one, so a villa excluded by property_type=villa can appear under property_type=villa,apartment.
  • sort=price_drop also filters, to listings whose price actually fell. And sort=recommended is a ranking that gets retuned between releases, so the same query can reorder — page through it freely, but don't sync with it.
  • compound=true is a special case meaning "in any compound", not a compound named "true". Use in_compound if that's what you meant.

Counts won't match darak.app exactly

Both now serve all live inventory, so the two should agree closely. Where they differ it's the ranking and the outlier filter, not a freshness window — darak.app used to hide listings whose source hadn't restated an update date in 30 days, which turned out to exclude a fifth of live listings and to depend almost entirely on which source published them. That filter is gone.