About Reelly

Reelly is a digital platform for real estate professionals, developers, and marketplaces. It provides access to a unified catalogue of real estate projects, developers, and related data through a simple and consistent API. The API is designed for integration into CRM systems, marketplaces, or partner platforms that need to display or analyze real estate information in real time.

Reelly’s API is built around read-only endpoints (GET requests only), giving partners secure and structured access to the platform’s data without altering source information.

What You’ll Achieve

• build property catalogs,
• power search and filter interfaces,
• integrate project listings into websites and CRM systems,
• fetch map-optimized markers,
• access dynamic dictionaries (countries, regions, statuses, etc.).

The API is fully read-only (GET-only).

This ensures safety, consistency, and prevents unauthorized changes.

Key Features

Environments & Base URL

Authentication

• Header Name: X-API-Key
• Value: Your unique API key provided by the Reelly sales team.

Your API Key is secret. Do not expose it in client-side code (frontend), do not publish it in public repositories, and do not share it with unauthorized third parties.

To obtain your API key, please contact Reelly Sales Department or your account manager. The key is unique for each client and must be included in every request header.

No IP or domain restrictions.

Authentication errors:

Core Entities Overview

Reelly data is organized into the following entity groups:

Endpoint Overview (Short Catalogue)

Metadata / Dictionaries

Developers

Projects

Units

Request Format

JSON is the primary and fully supported format, and it is used by default.

When format=xml is provided, the response is returned in XML, but the XML representation is simplified and may not reflect the full structure available in JSON.

Example:

GET /projects?country=Dubai&format=json

Response Structure & Conventions

JSON Structure

Responses may include:

• primitives (string, int, float, boolean)
• arrays
• nested objects

Geodata

Projects may include:

• polygon (LineString),
• latitude, longitude

Media

Image metadata follows a consistent structure:

{  "url": "https://...",  "metadata": {    "mime": "image/png",    "size": 689825,    "width": 500,    "height": 500  }}

Pagination

Some endpoints in the Reelly Clients API use a consistent offset-based pagination model.

Pagination ensures predictable performance, stable response times, and efficient data handling for large datasets.

Clients should always use pagination when retrieving collections, especially:

• when rendering large lists (projects, markers, units),
• when syncing data to local storage,
• when building infinite-scroll or “Load more” interfaces,
• when exporting or processing datasets incrementally.

If pagination parameters are not provided, default values are applied.

The API does not return the full dataset in a single response when the result is large — instead, the client must follow the next URLs provided in the response.

Pagination Parameters

limit

offset

Pagination Fields in Responses

All paginated endpoints return the same envelope:

Example:

{  "count": 1906,  "next": "https://api-reelly.up.railway.app/api/v2/clients/projects?limit=20&offset=20",  "previous": null,  "results": [    { "...": "..." }  ]}

Typical Usage

Get the first page (default pagination)

GET /api/v2/clients/projects

Get the second page

GET /api/v2/clients/projects?limit=20&offset=20

Increase or decrease page size

GET /api/v2/clients/projects?limit=50

Jump to an arbitrary offset (example: page 10 with 20 items per page)

GET /api/v2/clients/projects?limit=20&offset=180

Behavior Notes

• next and previous always contain fully constructed URLs that can be called directly.
• When there is no additional data, next becomes null.
• When the first page is requested, previous is always null.
• Pagination works identically across all list endpoints, including:
  • /projects
  • /projects/markers
  • /units
  • /developers
  • all metadata lists

Multilingual Support

All clients/api/v2 endpoints support the language query parameter, which controls the language of text content returned in the response.

When this parameter is provided, the API returns translatable text fields and human-readable labels in the requested language. If a translation is not available for a specific field, the API falls back to English (en-us) without error.

How It Works

The language parameter affects two categories of content:

Note: The language parameter affects only the representation of text values in the response. It does not influence filtering, sorting, pagination, currency conversion, or area unit conversion.

Fallback Behavior

Translation coverage varies by field and language. The API applies the following fallback rules:

• If a translation exists for the requested language — it is returned.
• If a translation does not exist for a specific field — the field is returned in English (en-us).
• If the language parameter is omitted — all content is returned in English by default.
• Fallback is applied per field independently — a single response may contain some fields translated and others in English.

Supported Languages

To get the current list of supported language codes, use:

GET /api/v2/clients/projects/languages

The following languages are confirmed to return translated content:

Note: The /projects/languages endpoint may return additional language codes. Only the languages listed above are confirmed to return translated content. Other codes fall back to English (en-us).

Usage Examples

Request project list with Russian localization:

GET /api/v2/clients/projects?language=ru

Request project details with German localization:

GET /api/v2/clients/projects/2211?language=de

Combined with other parameters — language is fully independent:

GET /api/v2/clients/projects?language=tr&preferred_currency=AED&limit=20

Notes

• The language parameter is supported across all clients/api/v2 endpoints.
• Always retrieve valid language codes from /api/v2/clients/projects/languages — do not hardcode language codes in your integration.
• Translation coverage is continuously expanding. Fields not yet translated fall back to English silently.
• The parameter value is case-sensitive. Use codes exactly as returned by the /projects/languages endpoint (e.g., en-us, not EN-US).

Rate Limits

The Reelly API does not enforce fixed rate limits. Partners can use the API freely under normal conditions.

In cases of peak load or unusual traffic patterns, Reelly reserves the right to apply request limits on an individual basis, as agreed with the partner.

If you anticipate high request volumes, please contact your Reelly account manager in advance.

If limits are exceeded:

HTTP 429 Too Many Requests

Recommended:

• cache dictionary endpoints,
• avoid unnecessary loops,
• use pagination (recommended pattern described below).

Error Handling

Standard HTTP Codes

First Request: Projects List

To get started, try the Projects List endpoint — it returns the list of real estate projects available through the Reelly platform.

GET https://api.reelly.io/apiv2/clients/projectsHeaders: X-API-Key: your_api_key_here

Support and Contact

For API support, questions, or feedback:

• Email: [email protected]
• Documentation site: docs.reelly.ai