Skip to main content
Imobzi is a real estate management platform designed for property professionals. It provides tools for managing properties, clients, sales processes, and marketing campaigns to help real estate agents and agencies streamline their operations and grow their business.

​
Configuring Imobzi as a Source

In the Sources tab, click on the “Add source” button located on the top right of your screen. Then, select the Imobzi option from the list of connectors. Click Next and you’ll be prompted to add your access.

​
1. Add account access

You’ll need to provide your API credentials to connect to Imobzi. Check Imobzi documentation to discover where you can find the API Key for the connection. The key must be created by an administrator in Imobzi under Integrations and Automations > API Keys. The following configuration is available:
  • API Token: Your Imobzi API key for authentication (sent via the X-Imobzi-Secret header) and access to the platform’s data.
Once you’re done, click Next.

​
2. Select streams

Choose which data streams you want to sync. For faster extractions, select only the streams that are relevant to your analysis. You can select entire groups of streams or pick specific ones.
Tip: The stream can be found more easily by typing its name.
Select the streams and click Next.

​
3. Configure data streams

Customize how you want your data to appear in your catalog. Select the desired layer where the data will be placed, a folder to organize it inside the layer, a name for each table (which will effectively contain the fetched data) and the type of sync.
  • Layer: choose between the existing layers on your catalog. This is where you will find your new extracted tables as the extraction runs successfully.
  • Folder: a folder can be created inside the selected layer to group all tables being created from this new data source.
  • Table name: we suggest a name, but feel free to customize it. You have the option to add a prefix to all tables at once and make this process faster!
  • Sync Type: you can choose between INCREMENTAL and FULL_TABLE.
    • Incremental: every time the extraction happens, we’ll get only the new data, which is good if, for example, you want to keep every record ever fetched.
    • Full table: every time the extraction happens, we’ll get the current state of the data, which is good if, for example, you don’t want to have deleted data in your catalog.
Once you are done configuring, click Next.

​
4. Configure data source

Describe your data source for easy identification within your organization, not exceeding 140 characters. To define your Trigger, consider how often you want data to be extracted from this source. This decision usually depends on how frequently you need the new table data updated (every day, once a week, or only at specific times). Optionally, you can define some additional settings:
  • Configure Delta Log Retention and determine for how long we should store old states of this table as it gets updated. Read more about this resource here.
  • Determine when to execute an Additional Full Sync. This will complement the incremental data extractions, ensuring that your data is completely synchronized with your source every once in a while.
Once you are ready, click Next to finalize the setup.

​
5. Check your new source

You can view your new source on the Sources page. If needed, manually trigger the source extraction by clicking on the arrow button. Once executed, your data will appear in your Catalog.
For you to be able to see it on your Catalog, you need at least one successful source run.

​
Streams and Fields

​
Available streams

The table below lists every stream, its slug (the exact identifier to pass when creating the source via API) and a short description.

​
Fields by stream

Below you’ll find all available data streams from Imobzi and their corresponding fields:
Activities of the Imobzi agenda: tasks, visits, calls and scheduled WhatsApp messages, with their type, date and whether they were completed. Each extraction rebuilds the table (full table): it reads every month of the agenda from January 2010 up to 12 months after the extraction date, so activities completed, canceled or rescheduled after their date are always up to date. Activities scheduled more than 12 months ahead are not included. Reading the whole agenda takes a few minutes on every extraction. The API key must be able to see the agenda of every user: if Imobzi returns no activity at all, the extraction fails and the table is kept as it was.
Stream for managing bank information and configurations.
Stream for managing contact bank account information.
Stream for managing real estate contracts and their details.
Stream for managing credit and financing analysis processes.
Stream for managing deal filtering configurations and criteria.
Stream for managing deal rotation processes and assignments.
Stream for managing document information and metadata.
Stream for managing financial account information and configurations.
Stream for managing contact tags and classifications.
Stream containing detailed information about deals.
One row per lost deal, with the loss reason and the comment chosen in Imobzi when the deal was marked as lost. Join it with Deals List on db_id. Imobzi only returns the loss reason in each deal’s own record, so this stream makes one request per lost deal: expect about 2 to 3 extra minutes of extraction for every 100 lost deals (around 15 minutes for 600 lost deals), since Imobzi answers these requests slowly and some have to be retried. The table is rebuilt on every extraction (full table): a deal that is reopened leaves it. If Imobzi cannot find the record of a lost deal during the extraction, the deal stays in the table without a loss reason and the run log says how many; the next extraction fills it in.
Stream for reporting on completed deals.
Stream containing a list of all deals.
Stream for managing reasons why deals are lost.
Stream for managing lease agreements and information.
Stream for managing media source information.
Stream for managing pipeline group configurations.
Stream for managing sales pipeline information.
Stream containing contact information and details.
Stream containing property listings and information.
Stream for managing financial transaction records.
Stream for managing property reservation information.
Stream containing detailed property information.

​
Data Model

The following diagram illustrates the relationships between the core data streams in Imobzi:

​
Implementation Notes

​
Rate Limiting and API Behaviors

  • Rate Limit: The Imobzi API strictly limits requests to 120 per minute per application and 300 per account. A throttled response returns 401 with a “rate limit” string in its body (instead of a standard 429). The connector anticipates this by automatically enforcing pacing (e.g., 0.55s between requests for single-call streams) and retrying seamlessly after 60 seconds if blocked.
  • IDs as Strings: Regardless of whether Imobzi responds with numerical integer IDs for certain resources (like deals and calendar items) or strings, the connector standardizes all output identifier fields (like db_id) strictly as strings.

​
Early In-Memory Reads (FULL TABLE)

Streams that iterate heavily over multiple endpoints (activities and deals_lost) utilize a memory-caching read logic. All relevant data is pulled entirely into memory prior to writing a SCHEMA message to your data warehouse. This ensures that any failures (like a rate-limit exhaustion or unpredictable data payloads) instantly abort the run, keeping your existing tables in the catalog entirely intact rather than leaving a partially-loaded table state.

​
Activities Sync Logic

  • Extracted natively from the GET /v1/calendar endpoint.
  • Since activities frequently change status without an “updated since” filter exposed by the API, activities uses a FULL_TABLE load type.
  • The stream programmatically crawls one-month windows per API call, checking continuously from January 2010 up to 12 months ahead of today’s date.
  • Items dynamically rescheduled during the connector’s running operation may be momentarily missed or appear twice until stabilized in the next scheduled execution.

​
Deals Lost Logic

  • Due to API constraints, the main KanBan or search views for deals do not expose contextual metadata such as the lost_reason and lost_comment.
  • The deals_lost stream first identifies lost deals globally through the list and then triggers one individual detail call per deal (GET /v1/deal/{deal_id}). Expect syncing times roughly close to 2.5 minutes per 100 historical lost deals.

​
Data Synchronization

  • Most streams support full table synchronization.
  • Some streams like property_details benefit from incremental sync to capture updates effectively using updated_at.
  • The connector safely serializes fractional numbers (decimals) inside nested JSON-string fields for streams like Property Details, preventing type conversion errors and extraction failures.
  • Pagination is automatically managed for large endpoints via JWT-powered cursors where necessary.

​
Skills for agents

Download Imobzi skills file

Imobzi connector documentation as plain markdown, for use in AI agent contexts.