This page explains how Reelly’s geospatial model works and how to integrate project markers into map-based interfaces.

The Projects Map Markers endpoint returns lightweight geographic markers for projects, optimized for use in interactive maps.

Each marker aggregates only the key attributes required to render a map pin and a minimal project card, keeping the payload compact even for large result sets.

Markers include:

• Core project identification (ID and name)
• Developer information (ID, name, logo)
• Basic location attributes (coordinates and administrative area)
• Minimal pricing information (min_price)
• Sale and construction statuses
• Cover image for map cards
• Partner flag

This endpoint is typically used together with the Projects list endpoint to keep the map view and list view synchronized under the same filter set.

Request

GET /api/v2/clients/projects/markers

Description

Returns an array of marker objects representing projects that match the provided filters.

Each marker contains only the fields needed for map rendering and quick identification, while the full project details remain available via:

• GET /api/v2/clients/projects — for paginated lists
• GET /api/v2/clients/projects/{id} — for complete project details

The filtering logic is aligned with the Projects list endpoint, so the same filter combinations that narrow the project list can be reused to narrow the marker set on the map.

Response Example

[    {        "id": 478,        "name": "320 Riverside Crescent",        "developer": {            "id": 56,            "name": "Sobha",            "logo": {                "url": "https://api.reelly.io/vault/ZZLvFZFt/2ICnZvNCBrZuhI218X9zNa2ZE8I/JfqF7w../1537869753264.jpeg",                "metadata": {                    "mime": "image/jpeg",                    "size": 280428,                    "width": 200,                    "height": 200                }            }        },        "location": {            "id": 300,            "latitude": 25.17710834882133,            "longitude": 55.325266620021395,            "country": 219,            "region": "Dubai",            "city": null,            "district": "Sobha Hartland 2",            "sector": "Meydan",            "village": null        },        "completion_datetime": "2027-07-31T00:00:00Z",        "cover_image": {            "url": "https://api.reelly.io/vault/ZZLvFZFt/ltB0PeYqF9paqGXLd4gTttDk-pU/1bO6CA../119.jpg",            "metadata": {                "mime": "image/jpeg",                "size": 373377,                "width": 1500,                "height": 1033            }        },        "sale_status": "on_sale",        "min_price": 2257081.99535,        "status": "under_construction",        "is_partner_project": false    }]

Typical Use Cases

• Rendering all relevant projects on an interactive map.
• Synchronizing the map with filters used in GET /projects (country, region, status, sale status, etc.).
• Implementing map clustering based on zoom level (grouping markers in dense areas).
• Highlighting filtered or selected results directly on the map.
• Displaying minimal project information in map popovers/tooltips (name, developer, price range, status).

Parameters

Below is the full list of supported parameters for the Map Markers endpoint.

Each parameter behaves exactly as in List Projects, except that filtering affects only which markers appear, not their internal structure.

bbox_ne_lat

Description

Defines the north-east latitude of the geographic bounding box used to filter map markers.

This parameter is part of a group of four coordinates (bbox_ne_lat, bbox_ne_lng, bbox_sw_lat, bbox_sw_lng) that together describe a rectangular region on the map.

Only projects whose location.latitude falls within the box are included in the response.

The filter is commonly used for viewport-based map rendering and incremental loading of nearby projects.

All four bbox parameters must be provided for filtering to be applied.

Meta

Request and Response Examples

Request — return markers within a visible map viewport:

GET /api/v2/clients/projects/markers?bbox_ne_lat=25.30&bbox_ne_lng=55.40&bbox_sw_lat=25.10&bbox_sw_lng=55.20

Example response fragment:

[  {    "id": 791,    "name": "48 Parkside",    "location": {      "latitude": 25.0559388,      "longitude": 55.23998939    },    "sale_status": "on_sale",    "status": "under_construction",    "min_price": 1159000.0149  }]

Notes

• Filtering is applied exclusively to latitude values inside project location objects.
• If any bbox parameter is missing, bounding box filtering is ignored.
• Latitude values must form a valid rectangle: ne_lat > sw_lat.

bbox_ne_lng

Description

Defines the north-east longitude of the bounding box.

Used together with the other three bbox parameters to filter markers to a specific map area.

Filtering applies to location.longitude, using standard geographic inequality rules.

Meta

Request Example

GET /api/v2/clients/projects/markers?bbox_ne_lat=25.30&bbox_ne_lng=55.40&bbox_sw_lat=25.10&bbox_sw_lng=55.20

Notes

• Both bbox_ne_lng and bbox_sw_lng must be included.
• If the bounding box values produce an inverted range (e.g., ne_lng < sw_lng), the result will be empty.

bbox_sw_lat

Description

Defines the south-west latitude of the bounding box.

Combined with the north-east latitude, it creates the vertical boundary for marker filtering.

Only markers with location.latitude >= bbox_sw_lat are included.

Meta

Request Example

GET /api/v2/clients/projects/markers?bbox_sw_lat=25.10&bbox_sw_lng=55.20&bbox_ne_lat=25.30&bbox_ne_lng=55.40

Notes

• Must be lower than bbox_ne_lat.
• Filter logic mirrors standard geographic map coordinates.

bbox_sw_lng

Description

Defines the south-west longitude of the bounding box.

This is the lower boundary of the longitude range used to filter markers.

Meta

Request Example

GET /api/v2/clients/projects/markers?bbox_sw_lng=55.20&bbox_sw_lat=25.10&bbox_ne_lat=25.30&bbox_ne_lng=55.40

Notes

• Must form a valid rectangle with the other bbox coordinates.
• Coordinates must be in decimal degrees.

completion_date_ranges

Description

completion_date_ranges allows clients to filter projects by estimated completion date using one or more UNIX timestamp ranges in UTC.

Each range is defined as:

• date_from-date_to — where both boundaries are UNIX timestamps in seconds.
• Multiple ranges are separated by commas.

A project is included in the marker response if its completion date falls into at least one of the specified ranges.

For Map Markers, this filter is applied to the same underlying completion data that is exposed as completion_datetime in the marker object:

"completion_datetime": "2025-11-30T01:00:00Z"

This parameter is useful when the consumer needs time-based filtering (for example, “projects completing between Q4 2024 and Q2 2026”) without relying on textual quarters or year-only filters.

Meta

Request and Response Examples

Get markers for projects completing between 1 January 2025 and 31 December 2025 (UTC):

GET /api/v2/clients/projects/markers?completion_date_ranges=1735689600-1767225599

Example response (fragment):

[  {    "id": 791,    "name": "48 Parkside",    "developer": {      "id": 222,      "name": "Tabeer Real Estate Development LLC"    },    "location": {      "latitude": 25.05593881164199,      "longitude": 55.239989393880585,      "country": 219,      "region": "Dubai",      "district": "Arjan"    },    "completion_datetime": "2025-11-30T01:00:00Z",    "cover_image": {      "url": "https://api.reelly.io/vault/ZZLvFZFt/shSUd9OwqGaN7UWSGbid_fkhXnI/oFtoWw../6.jpg"    },    "sale_status": "on_sale",    "min_price": 1159000.0149,    "status": "under_construction",    "is_partner_project": false  }]

Using multiple ranges (for example, late 2024 or full 2026):

GET /api/v2/clients/projects/markers?completion_date_ranges=1730332800-1735603199,1767225600-1798761599

Notes

• Time zone: all timestamps must be in UTC and expressed in seconds (standard UNIX time).
• Each range must have date_from <= date_to.
• When multiple ranges are provided, a project is included if its completion date falls into at least one of them.
• The parameter is applied at the project level; only markers for matching projects are returned.
• Can be safely combined with other filters such as country, region, sale_status, and bounding-box parameters.

completion_quarters

Description

completion_quarters filters projects by their declared completion quarter, as used in the project metadata (for example, "Q2 2028").

Unlike completion_date_ranges, which uses precise UNIX timestamps, this parameter works on a higher-level, human-readable representation of completion time.

The accepted values match the labels returned by the relevant metadata endpoint (for example, GET /api/v2/clients/projects/completion-quarters, if exposed in your environment).

For Map Markers, this parameter restricts which projects are included; matching markers still expose the underlying completion_datetime field.

Multiple quarters can be passed at once, separated by commas.

Meta

Request and Response Examples

Filter markers for projects completing in Q4 2025:

GET /api/v2/clients/projects/markers?completion_quarters=Q4%202025

Filter markers for projects completing in Q4 2025 or Q1 2026:

GET /api/v2/clients/projects/markers?completion_quarters=Q4%202025,Q1%202026

Example response (fragment):

[  {    "id": 2353,    "name": "77 Boulevard",    "developer": {      "id": 500,      "name": "BAMX Development"    },    "location": {      "latitude": 25.04726100764794,      "longitude": 55.199750290722136,      "country": 219,      "region": "Dubai",      "district": "JVC (Jumeirah Village Circle)"    },    "completion_datetime": "2026-09-30T00:00:00Z",    "sale_status": "out_of_stock",    "min_price": 0,    "status": "presale",    "is_partner_project": false  }]

Notes

• Values must match the labels returned by the corresponding metadata endpoint (for example, "Q2 2028").
• If a value contains spaces, it must be URL-encoded (for example, "Q2 2028" → Q2%202028).
• Multiple quarters are treated as a logical OR — a project is included if its declared completion quarter matches any of the provided values.
• Can be combined with completion_date_ranges, but in этом случае клиентам рекомендуется явно контролировать, какие фильтры они ожидают применять (точные даты vs. кварталы).

country

Description

Filters map markers by the numeric country ID associated with the project location. The value must match the country field inside location objects returned by the markers endpoint.

Filtering is exact and numeric; text values (e.g., “UAE”) are not accepted.

If the provided ID does not correspond to any country present in the system, the API returns an empty result set.

Meta

Request Example

GET /api/v2/clients/projects/markers?country=219

Response Fragment

[  {    "id": 766,    "name": "555 Park Views",    "location": {      "country": 219,      "region": "Dubai",      "district": "JVC (Jumeirah Village Circle)",      "latitude": 25.0340806,      "longitude": 55.17409039    },    "status": "completed",    "sale_status": "out_of_stock"  }]

Notes

• Marker responses return only the numeric country ID.

• For the list of available countries use:

  GET /api/v2/clients/countries

• Commonly used together with region and district filters.

developer

Description

Filters the marker list by developer.

When this parameter is set, only projects belonging to the specified developer are included in the marker response.

The parameter uses the developer ID, as returned by developer-related metadata or list endpoints.

This is especially useful for building views such as “all current projects of a particular developer on the map”.

Meta

Request and Response Examples

Filter markers for a specific developer:

GET /api/v2/clients/projects/markers?developer=222

Example response (fragment):

[  {    "id": 791,    "name": "48 Parkside",    "developer": {      "id": 222,      "name": "Tabeer Real Estate Development LLC",      "logo": {        "url": "https://api.reelly.io/vault/ZZLvFZFt/0KpFZCcDuj8RXD_dFmBteBSzpKY/9-uLbA../Frame+21.png"      }    },    "location": {      "id": 306,      "latitude": 25.05593881164199,      "longitude": 55.239989393880585,      "country": 219,      "region": "Dubai",      "district": "Arjan",      "sector": "Al Barsha",      "village": null    },    "completion_datetime": "2025-11-30T01:00:00Z",    "cover_image": {      "url": "https://api.reelly.io/vault/ZZLvFZFt/shSUd9OwqGaN7UWSGbid_fkhXnI/oFtoWw../6.jpg"    },    "sale_status": "on_sale",    "min_price": 1159000.0149,    "status": "under_construction",    "is_partner_project": false  }]

Notes

• The value must match a valid developer identifier from the Developers metadata or list.
• Can be combined with geographic filters (country, region, districts) and commercial filters (sale_status, status, completion filters) to build focused map views.
• Marker responses always return the developer object (ID, name, and logo), not just the ID.

districts

Description

Filters the marker list by one or several districts.

This parameter expects a list of district IDs, as defined by the Districts metadata or locations APIs.

When provided, only markers for projects whose locations belong to the specified districts are returned.

This is especially useful for map-based search and location-focused pages where user selects specific districts on the map or via UI filters.

Meta

Request and Response Examples

Filter markers in a single district:

GET /api/v2/clients/projects/markers?districts=306

Filter markers in multiple districts:

GET /api/v2/clients/projects/markers?districts=306,309,310

Example response (fragment):

[  {    "id": 766,    "name": "555 Park Views",    "developer": {      "id": 223,      "name": "Serene Developments"    },    "location": {      "id": 308,      "latitude": 25.034080619854226,      "longitude": 55.17409039107837,      "country": 219,      "region": "Dubai",      "district": "JVT (Jumeirah Village Triangle)",      "sector": "Jumeirah Village Circle",      "village": null    },    "completion_datetime": "2024-06-30T00:00:00Z",    "cover_image": {      "url": "https://api.reelly.io/vault/ZZLvFZFt/eQP-LhaGMgXH_AFLGx0S26CCIgo/sBI2Ag../8.jpg"    },    "sale_status": "out_of_stock",    "min_price": 0,    "status": "completed",    "is_partner_project": false  }]

Notes

• Each value must correspond to a valid district identifier from the Districts metadata (or Locations API).
• When multiple IDs are provided, a project is included if it belongs to any of the specified districts (logical OR).
• Can be freely combined with country, region, price filters, status filters, and completion filters.
• Marker responses return both the district ID and the district name inside the location object.

has_escrow

Description

Filters map markers by whether a project has an active escrow account.

This parameter does not modify the marker payload, as escrow data is not included in the map marker response structure.

Instead, it restricts the result set to projects where an escrow account exists (true) or does not exist (false), based on backend business logic.

This filter is commonly used in compliance-oriented interfaces, marketplaces, and UAE regulatory–compliant workflows where buyers may prefer projects with financial safeguards.

Meta

Request and Response Examples

Filter only projects with escrow:

GET /api/v2/clients/projects/markers?has_escrow=true

Filter only projects without escrow:

GET /api/v2/clients/projects/markers?has_escrow=false

Example response fragment:

[  {    "id": 2353,    "name": "77 Boulevard",    "location": {      "latitude": 25.047261,      "longitude": 55.199750,      "country": 219,      "region": "Dubai",      "district": "JVC (Jumeirah Village Circle)"    },    "sale_status": "out_of_stock",    "min_price": 0,    "status": "presale"  }]

Notes

• The filter accepts standard boolean values: true or false.
• Escrow information is never included in the marker payload.
• Filtering logic matches the one used in Projects List (same project selection rules).
• Safe to combine with any other filter.

language

Description

Specifies the language code for the response. This parameter is accepted by the endpoint for consistency with other API endpoints, but has no practical effect on the response content.

post_handover

Description

Filters markers by whether the project offers a post-handover payment plan.

Marker objects do not expose payment plan details, but this filter restricts results to projects that have at least one payment plan flagged as post-handover.

Useful for users searching specifically for flexible payment plan options.

Meta

Request and Response Examples

Filter only projects with post-handover payment plans:

GET /api/v2/clients/projects/markers?post_handover=true

Combined example with region:

GET /api/v2/clients/projects/markers?region=Dubai&post_handover=true

Response fragment:

[  {    "id": 791,    "name": "48 Parkside",    "sale_status": "on_sale",    "status": "under_construction",    "min_price": 1159000.0149  }]

Notes

• Payment plan data is not included in marker responses.
• This filter simply limits which projects are considered.
• Works identically to Projects List filtering.

preferred_area_unit

Description

Specifies the preferred measurement unit for sizes.

However, map marker responses do not include any size fields (min_size, max_size, unit sizes, area_unit).

Therefore:

• The parameter is accepted,
• but does not modify the marker response in any way.

Valid values are the same as in Projects List:

• m2
• sqft (default)

If an unsupported value is passed, the API echoes it back internally but continues to use sqft for all internal calculations (marker response remains unchanged).

Meta

Request Example

GET /api/v2/clients/projects/markers?preferred_area_unit=m2

Response fragment (unchanged):

{  "id": 1866,  "name": "4B Living",  "min_price": 0,  "area_unit": "sqft",   // unchanged in marker response  "sale_status": "out_of_stock",  "status": "under_construction"}

Notes

• The value does not affect the response structure because area fields are not present.
• The parameter exists for consistency across endpoints.
• It can still be combined with other filters safely.

preferred_currency

Description

Converts monetary values (specifically, min_price) into the requested currency.

The Map Markers response contains only one currency field derived from the preferred currency selection:

"min_price": <numeric>,"price_currency": "USD"

Supported currencies:

• AED
• USD

If an unsupported value is passed, the API falls back to AED internally but continues to echo the provided value in the request processing logic.

This parameter is commonly used to match UI currency preferences or region-based pricing.

Meta

Request and Response Examples

Request in USD:

GET /api/v2/clients/projects/markers?preferred_currency=USD

Response fragment:

{  "id": 791,  "name": "48 Parkside",  "min_price": 315000.55,  "price_currency": "USD",  "sale_status": "on_sale",  "status": "under_construction"}

Request in AED:

GET /api/v2/clients/projects/markers?preferred_currency=AED

Response fragment:

{  "id": 791,  "name": "48 Parkside",  "min_price": 1159000.0149,  "price_currency": "AED"}

Invalid value:

GET /api/v2/clients/projects/markers?preferred_currency=GBP

Response (markers still in AED internally):

{  "min_price": 1159000.0149,  "price_currency": "AED"}

Notes

• Conversion logic matches Projects List.
• Only min_price is converted (no max price exists in marker payload).
• Always verify currency support before dynamically generating UI filters.

price_type

Description

Specifies how the unit price range filters (unit_price_from and unit_price_to) should be interpreted when selecting projects for map markers.

• When set to unit, the API treats the price range as the total price of a unit (for example, a full apartment or villa).
• When set to area, the API treats the price range as price per area unit (for example, per square foot or per square meter, depending on preferred_area_unit).

This allows clients to search either by total ticket size or by price per square unit, using the same numeric range parameters.

For the Map Markers endpoint, price_type affects which projects are included in the marker response, but the marker payload itself still exposes only min_price (the minimum project price) and does not distinguish between total price and price per area unit in its structure.

Meta

Request and Response Examples

Request: filter by total unit price (default behavior, equivalent to omitting price_type):

GET /api/v2/clients/projects/markers?unit_price_from=2000000&unit_price_to=4000000&price_type=unit

Request: filter by price per area unit (for example, per m² or per sqft, depending on preferred_area_unit):

GET /api/v2/clients/projects/markers?unit_price_from=2000&unit_price_to=4000&price_type=area&preferred_area_unit=m2

Example response fragment (Map Markers structure):

[  {    "id": 2211,    "name": "Jacob and Co Beachfront Living",    "developer": {      "id": 500,      "name": "Sample Developer"    },    "location": {      "id": 309,      "country": 219,      "region": "Dubai",      "district": "JVC (Jumeirah Village Circle)",      "latitude": 25.047261,      "longitude": 55.199750    },    "completion_datetime": "2026-09-30T00:00:00Z",    "cover_image": {      "url": "https://api.reelly.io/vault/..."    },    "sale_status": "on_sale",    "min_price": 3044499.0,    "status": "under_construction",    "is_partner_project": false  }]

Notes

• Allowed values:
  • unit – treat unit_price_from / unit_price_to as total unit price.
  • area – treat unit_price_from / unit_price_to as price per area unit (according to preferred_area_unit).
• If price_type is omitted, the API behaves as if price_type=unit is used.
• price_type should always be used together with unit_price_from and/or unit_price_to; by itself it does not apply any price filter.
• For the Map Markers endpoint, price_type influences project selection, but the marker payload still contains a single min_price value without explicitly indicating whether it comes from total-price or per-area filtering.
• On the client side it is recommended to:
  • clearly label filters in the UI (for example, “Total price” vs “Price per m²”),
  • ensure that entered numeric values match the interpretation selected via price_type.

project_ids

Description

Filters map markers by a set of project IDs.

This parameter allows clients to explicitly request markers for one or more known projects.

It is useful for:

• highlighting specific projects on the map,
• loading only selected items (for example, from search results or a favorites list),
• synchronizing list and map displays when only a subset of results must be shown.

Multiple IDs must be provided as a comma-separated list.

Only project IDs that exist in the system are returned; invalid IDs are silently ignored.

Meta

Request and Response Examples

Filter by a single project ID:

GET /api/v2/clients/projects/markers?project_ids=791

Multiple IDs:

GET /api/v2/clients/projects/markers?project_ids=791,1866,2353

Response fragment:

[  {    "id": 791,    "name": "48 Parkside",    "sale_status": "on_sale",    "status": "under_construction",    "min_price": 1159000.0149  },  {    "id": 1866,    "name": "4B Living",    "sale_status": "out_of_stock",    "status": "under_construction",    "min_price": 0  }]

Notes

• IDs must be numbers, not strings.
• Invalid or non-existing IDs do not cause errors; they simply return no matching marker.
• The order of IDs does not affect the response.
• Can be combined with any other filters, but if filters contradict the ID list, the result may be empty.

region

Description

Filters markers by region name.

The value must match one of the region names returned by the metadata endpoint:

GET /api/v2/clients/regions

Filtering is case-insensitive, but the string must match the canonical region name.

Only markers whose location.region field equals the provided region are returned.

This filter is commonly used for map navigation within a specific emirate or geographical subdivision.

Meta

Request and Response Examples

Fetch valid regions:

GET /api/v2/clients/regions

Example values:

[  "Dubai",  "Abu Dhabi Emirate",  "Ras Al Khaimah",  "Sharjah"]

Filter markers by region:

GET /api/v2/clients/projects/markers?region=Dubai

Response fragment:

[  {    "id": 766,    "name": "555 Park Views",    "location": {      "country": 219,      "region": "Dubai",      "district": "JVT (Jumeirah Village Triangle)"    },    "sale_status": "out_of_stock",    "status": "completed",    "min_price": 0  }]

Notes

• Must use the exact region name returned by metadata (spaces must be URL-encoded).
• Region must logically match the selected country if both filters are used.
• Projects with empty or null region fields will not match any region filter.

sale_status

Description

Filters map markers by the project’s sale status.

The parameter accepts:

• human-readable values, e.g. On Sale, Out of Stock
• snake_case values, e.g. on_sale, out_of_stock

Marker responses always return snake_case Sale Status.

This filter is commonly used to show only:

• projects currently selling (on_sale),
• future launches (presale),
• sold-out projects (out_of_stock).

Input is flexible — both formats yield the same results.

Meta

Allowed values

Request and Response Examples

Request using human-readable value:

GET /api/v2/clients/projects/markers?sale_status=On%20Sale

Request using snake_case:

GET /api/v2/clients/projects/markers?sale_status=on_sale

Response fragment:

[  {    "id": 791,    "name": "48 Parkside",    "sale_status": "on_sale",    "status": "under_construction",    "min_price": 1159000.0149  }]

Notes

• Input is flexible; output is always canonical snake_case.
• Matches Projects List filter logic exactly.
• Safe to combine with status, region, country, bounding box, and price filters.
• If an unknown value is submitted, the API returns an empty result set.

search_query

Description

Performs a text search across multiple project fields:

• project name
• developer name
• district or area name

Search behavior:

• case-insensitive
• substring match (not full word match)
• applied before pagination and before bounding box filtering

Unlike the Projects List endpoint, Map Markers do not include descriptions or amenities, so search is performed only on high-level project identification fields.

Meta

Request and Response Examples

GET /api/v2/clients/projects/markers?search_query=Park

Response fragment:

[  {    "id": 791,    "name": "48 Parkside",    "developer": { "name": "Tabeer Real Estate Development LLC" },    "location": { "district": "Arjan" },    "sale_status": "on_sale"  },  {    "id": 766,    "name": "555 Park Views",    "developer": { "name": "Serene Developments" },    "location": { "district": "JVT (Jumeirah Village Triangle)" }  }]

Notes

• Search includes project name, developer name, and district names.
• Search does not include overview, description, amenities, or unit data (not present in markers).
• Often combined with bbox filters to show search results only within the visible map area.

status

Description

Filters markers by the project’s construction status.

The parameter accepts:

• canonical text values from metadata (e.g., Under Construction, Completed),
• snake_case values (e.g., under_construction, completed).

Marker responses always use the canonical snake_case form:

"status": "under_construction"

Status values describe the lifecycle phase of the project and are typically used to distinguish:

• completed projects,
• ongoing construction,
• presale or planning stages.

Meta

Allowed values

Request and Response Examples

Using readable text:

GET /api/v2/clients/projects/markers?status=Under%20Construction

Using snake_case:

GET /api/v2/clients/projects/markers?status=under_construction

Response fragment:

[  {    "id": 766,    "name": "555 Park Views",    "sale_status": "out_of_stock",    "status": "completed",    "min_price": 0  }]

Notes

• Behavior is fully aligned with Projects List filtering.
• Marker responses always use snake_case.
• If an unsupported value is submitted, the API returns zero results.
• Can be safely combined with sale_status, region, and bounding box filters.

unit_area_from

Description

Filters map markers by the minimum unit size available within a project.

The parameter acts on the project’s underlying unit inventory, not on data exposed in the marker response (markers do not contain size fields).

The value is interpreted according to preferred_area_unit:

• m2 — alias for square meters
• sqft — square feet (default)

A project is included in the result set if any of its units has an area greater than or equal to the value provided.

Since map markers do not display size information, this filter affects which markers are shown, but not their payload.

Meta

Request and Response Examples

Filter projects with units ≥ 700 sqft:

GET /api/v2/clients/projects/markers?unit_area_from=700

Filter in square meters:

GET /api/v2/clients/projects/markers?unit_area_from=65&preferred_area_unit=m2

Response fragment (marker payload; areas are not shown):

[  {    "id": 282,    "name": "7 Park Central By Meteora",    "sale_status": "out_of_stock",    "status": "under_construction",    "min_price": 3529139.9962  }]

Notes

• This filter is purely backend-driven; no size values appear in markers.
• Internally compares against project-level min_size / max_size, even though they are not returned.
• Should be combined with preferred_area_unit if filtering in metric units.

unit_area_to

Description

Defines the maximum allowed unit size for filtering project markers.

A project qualifies if any of its units has area less than or equal to the provided upper limit.

As with unit_area_from, this affects only project selection.

Markers themselves do not contain min_size, max_size, or any other area-related fields.

Meta

Request Examples

Units ≤ 1200 sqft:

GET /api/v2/clients/projects/markers?unit_area_to=1200

Units ≤ 110 m²:

GET /api/v2/clients/projects/markers?unit_area_to=110&preferred_area_unit=m2

Example response (fragment):

[  {    "id": 766,    "name": "555 Park Views",    "sale_status": "out_of_stock",    "status": "completed",    "min_price": 0  }]

Notes

• Matches backend unit size filtering rules.
• Must be combined with preferred_area_unit when filtering in metric units.
• Can be used together with unit_area_from to define a size range.

unit_bedrooms

Description

Filters projects by the number of bedrooms available in their unit inventory.

A project is included in the response if at least one of its units has a bedroom count matching any of the values provided in unit_bedrooms.

The parameter accepts:

• integer values such as 0, 1, 2, 5, 11
• decimal values when such values are present in the data (e.g., 1.5)
• multiple values, comma-separated
  • These are evaluated as logical OR

Example: unit_bedrooms=1,5 returns projects that offer either 1-bedroom or 5-bedroom units.

This filter operates on unit-level data (typical_units, inventory attributes), even though bedroom information is not included in the map marker response structure.

Meta

Request and Response Examples

Filter projects offering studio units (0 bedrooms):

GET /api/v2/clients/projects/markers?unit_bedrooms=0&limit=50

Filter projects offering 1-bedroom units:

GET /api/v2/clients/projects/markers?unit_bedrooms=1&limit=50

Filter projects offering either 1 or 5 bedrooms:

GET /api/v2/clients/projects/markers?unit_bedrooms=1,5&limit=50

Filter projects offering 11-bedroom units:

GET /api/v2/clients/projects/markers?unit_bedrooms=11&limit=50

Filter projects with fractional bedroom counts, when present:

GET /api/v2/clients/projects/markers?unit_bedrooms=1.5&limit=50

Notes

• Comma-separated values are treated as logical OR.
• The filter supports integer and decimal bedroom values.
• If none of the specified bedroom counts exist in project unit data, the result set will be empty.
• The filter can be used together with all other project filters such as price ranges, unit types, location filters, and status filters.
• Bedroom counts are evaluated based on the project’s unit inventory; map marker responses do not include bedroom information directly.