Enterprise API (1.0.1)

Property Finder provides a collection of APIs that enable you to integrate with our various products and services. Our APIs use JSON for request and response bodies and employ standard HTTP response codes. You can consume the APIs directly using any HTTP or REST library.

For any additional support or questions related to the integration, please contact us at integration.support@propertyfinder.ae.

Usage Restrictions

This API is intended strictly for server-to-server communication.

• Do not use this API directly from frontend applications (e.g., browsers, mobile apps).
• Do not use this API as a Backend-for-Frontend (BFF) for public or semi-public client apps.
• Requests should originate from secure, server-side environments only.

The following sections cover below mentioned topics:

• Authentication
• Authorization - Enterprise API Keys
• Rate Limiting

When working with the API, you need to pass an access token in the Authorization header of all your requests. This will be in the form of a Bearer token, for example: Bearer <ACCESS_TOKEN>

Obtaining the token

To obtain the token, you will need OAuth 2.0 credentials. Your OAuth 2.0 credentials consist of an API Key and an API Secret (corresponding to OAuth 2.0 client ID and client secret).

Getting OAuth 2.0 credentials

To get your OAuth 2.0 credentials, open the PF Expert application, and log in. Once you are logged in, navigate to the API Credentials section under the Developer Resources tab in the left sidebar. From here, you can generate a new API key and API secret. Be sure to use the type as API Integration.

You can exchange these for an access token by calling the Issue JWT Token Endpoint. You can pass the API key and API secret in the request body.

API Key : Your unique client identifier on PF Expert.
API Secret : Your client secret, used for authentication when requesting an access token.

Example request

curl --location 'https://atlas.propertyfinder.com/v1/auth/token' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--data 
' 
  {
    "apiKey":"<API_KEY>",
    "apiSecret":"<API_SECRET>"
  }
'

The token server will return a Bearer accessToken in JSON Web Token (JWT) format which you should use in the Authorization header of your API requests.

Example response

{
  "accessToken": "<ACCESS_TOKEN>",
  "expiresIn": 1800,
  "tokenType": "Bearer"
}

Example request

curl --location 'https://atlas.propertyfinder.com/v1/users?page=1&perPage=15' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer <ACCESS_TOKEN>'

Your access token will be valid for the duration (in seconds) indicated by the expiresIn field in the response. When it expires, you'll need to request a new one. Currently, an issued access token will expire in 30 minutes. Once a token expires, you must request a new one. No refresh token flow is supported in this integration.

Unauthorized Requests

If you attempt to access a protected resource without valid authorization you will receive a 401 Unauthorized or 403 Forbidden HTTP error.

  HTTP/1.1 401 Unauthorized
  Content-Type: application/json
  {
    "detail": "access denied (decision id: 5593a6df-2c67-4891-bd0a-83f3edfe9b14)",
    "title": "Unauthorized",
    "type": "AUTHENTICATION"
  }

Enterprise API keys are generated in PF Expert > Developer Resources and provide authenticated access to the PF API. API keys support scope-based authorization and enforced expiration to control access and manage key lifecycle.

Authorization

• Each API key is created with explicitly assigned scopes.
• Scopes define which API endpoints and operations the key is authorized to access.
• Requests made to endpoints outside the assigned scopes are rejected.
• Once API keys are created, their scopes and configuration cannot be modified.

Default Scopes

The following scopes are enabled by default and cannot be disabled:

• Compliance: compliances:read
• Listing Verification: listing_verification:full_access
• Location: locations:read
• Project: projects:read
• Webhooks: webhooks:full_access

Optional Scopes

The following scopes can be enabled or disabled based on integration requirements:

• Users: users:read, users:full_access
• Listings: listings:read, listings:full_access
• Leads: leads:read
• Credits: credits:read
• Statistics: statistics:read
• Roles: roles:read

Endpoint Scope Requirements

• Each API endpoint requires a minimum scope. • Required scopes are documented at both:

• The endpoint level
• The Endpoint-to-Scope Mapping section • Possession of a valid API key alone does not grant access unless the required scope is enabled.

Expiration

• Expiry is required when generating a new API key.
• The maximum validity period for an API key is 365 days.
• After expiry, the API key is automatically invalidated and cannot be reused.
• A new API key must be generated to restore API access.

Endpoint-to-Scope Mapping

The minimum scope access required to access each endpoint is listed below. Scope requirements are also documented at the individual endpoint level.

Webhook Event-Based Permissions

When subscribing to webhook events, additional scope requirements apply based on the event type:

Required Scope by Event Type:

Unauthorised Scope Access

If you attempt to access an endpoint or event type without the required scope, you will receive a 403 Forbidden HTTP error:

HTTP/1.1 403 Forbidden
Content-Type: application/json
{
  "detail": "action not allowed (decision id: 212c6af7-a651-462e-8250-2139c1c83ee3)",
  "title": "Forbidden",
  "type": "AUTHORIZATION"
}

Best Practices

• Principle of Least Privilege: Only request scopes that your integration actually needs.
• Key Rotation: Plan for key expiration by implementing a key rotation strategy before the 365-day limit.
• Scope Documentation: When onboarding clients, clearly communicate which scopes your integration requires.

To ensure fair use and maintain high availability of our APIs, we enforce rate limiting on all requests made to our endpoints.

Default Rate Limits

Unless otherwise specified, all clients are subject to the following default limits:

Note: The rate limits are applied per IP address and per client. Other factors may also be considered.

If you exceed your allotted rate limit: You will receive a 429 Too Many Requests HTTP response. The request can then be safely retried after some time. Example:

HTTP/1.1 429 Too Many Requests

Best Practices

• To avoid frequently hitting the rate limit, retry requests using an incremental backoff with jitter.
• Cache responses for frequently accessed data to reduce duplicate API calls.

When uploading images for listings or other resources, please ensure your images meet the following technical requirements to ensure optimal display quality and prevent processing issues.

Accepted File Types

The following image formats are supported:

• JPEG/JPG (image/jpeg)
• PNG (image/png)
• WebP (image/webp)

File Size

• Minimum: 5 KB per image
• Maximum: 15 MB per image

Images outside this range may fail to upload or process correctly.

Color Space Requirements

Supported color spaces:

• ✅ sRGB (recommended)
• ✅ Adobe RGB
• ✅ RGB

Not supported:

• CMYK

  Important: CMYK color space is NOT supported. Images using CMYK may appear oversaturated or display incorrect colors when shown on the Property Finder website. Please convert CMYK images to sRGB before uploading to ensure accurate color representation.

Aspect Ratio and Resolution

Recommended aspect ratio:

• Landscape orientation (e.g., 16:9, 4:3)

Maximum resolution:

• 1920 x 1080 pixels

Images with higher resolutions will be automatically resized to fit within these dimensions while maintaining aspect ratio.

Image URL Requirements

• Images must be accessible via publicly accessible URLs or signed URLs
• URLs must use HTTPS protocol
• URLs must remain valid and accessible for at least 7 days to allow our system to reliably download and process the images
• Signed URLs with limited expiry are supported and recommended for security
• Property Finder IPs must be whitelisted to allow image downloads from your servers. Contact tech support to obtain the required IPs.

Watermark Requirements

If you upload custom watermarks, please ensure they meet the following specifications:

• Supported formats: PNG, WebP
• File size: Between 2 KB and 5 MB
• Maximum resolution: 1920 x 1080 pixels (1080p)

Best Practices

• Use sRGB color space for best results across all devices and browsers
• Maintain 16:9 aspect ratio
• Use JPEG image format
• Use landscape orientation for property images to ensure proper display
• Ensure URLs are accessible from our servers (not behind firewalls or requiring authentication)
• Test your image URLs before submitting to avoid upload failures

• Every listing must be associated with a Public Profile representing the identity of a PF Expert user responsible for the listing, as displayed publicly on the Property Finder website. Public profiles are associated with PF Expert users, and can be retrieved using the [GET] /v1/users endpoint.

• Every listing must be associated with a valid Location from Property Finder's location tree.

• Every listing must include at least one image that meets our Image Requirements.

• The list of accepted amenities depends on both the Property Type and Category of the listing.

  • See country-specific rules below for allowed combinations.

• The listing creation process is split into two steps:

  • Creating the listing in draft mode ([POST] /v1/listings)
  • Publishing the listing ([POST] /v1/listings/{id}/publish)

1. Obtain Public Profile Id
   Call [GET] /v1/users to retrieve available users and their public profiles. select the appropriate publicProfile.id.

    {
     "publicProfile": {
       "id": 216582,
       ...
      }
      ...
    }
   

2. Obtain Location ID
   Call [GET] /v1/locations?search=Marina to retrieve the valid location and obtain the correct id.

      {
        "data": [
          {
            "coordinates": {
              "lat": 25.078367,
              "lng": 55.14041
            },
            "id": 50,
            "name": "Dubai Marina",            
            ...
          }
        ]
      }
   

3. Create Listing (Draft Mode)
   Call ([POST] /v1/listings) to create a new listing in draft state, providing the required data including publicProfileId and locationId. The response will return the newly created listingId.

4. (Optional) Get Publishing Price
   Call [GET] /v1/listings/{id}/publish/prices to retrieve the price to publish the listing.

5. Publish Listing
   Call [POST] /v1/listings/{id}/publish to publish the listing and make it publicly available on the Property Finder website.

6. Listing Publish Flow

Note: Listing publishing is an asynchronous process.
A 200 OK response only confirms that the request was received, not that the listing was successfully published.

Recommended Flow:

1. Subscribe to the Publish Webhook

• Subscribe to the Publish Webhook.
• This webhook notifies you when a listing has been successfully published.

2. Publish the listing

• Send a POST request to publish the listing by calling the Publish Listing Endpoint.
• You will receive an immediate 200 OK response (request accepted).

3. Wait for Webhook Notification

• If you receive a success notification within 30 seconds, the listing is confirmed as published.

4. Verify Listing API if Needed

• If no webhook notification is received within 30–60 seconds, call the GET Listing API to verify the current listing status.

Common Pitfall:

• Do not mark listings as created immediately after receiving a 200 OK response.
• In some cases, the listing may fail to publish, leading to inconsistencies between CRM system and PF Expert.
• Implementing the above flow helps ensure accurate status tracking and resolves missing listings issues.

The following table shows how field names differ between the UI and the API for Dubai and ADREC (Abu Dhabi) contexts:

DUBAI

To ensure compliance with the Dubai Land Department's (DLD) regulations, particularly under the DLD Strict Adherence initiative, it's imperative that all property listings on Property Finder accurately reflect the details registered with the DLD. This includes critical information such as price, property type, and location.
To facilitate this, our Enterprise API provides a structured workflow that mandates the retrieval of official permit details before creating or updating any listing.

Special Business Rules

• Dubai Land Department (DLD) compliance is mandatory for listings in Dubai.
• Permit ID and License Number must be obtained before creating or updating listings.
• Listing verification is automatically triggered after publishing.
• Listings located within DIFC and JAFZA are exempt from DLD compliance and permit validation.
• Only developer clients may use project-level permits to publish listings; brokers must obtain unit-level permits.

High-Level UAE Flow (Dubai-specific)

1. Retrieve Public Profile ID ([GET] /v1/users)
2. Retrieve Location ID ([GET] /v1/locations)
3. Retrieve Permit Details ([GET] /v1/compliances/{permitNumber}/{licenseNumber})
4. Create Listing ([POST] /v1/listings with permit and license details
5. Publish Listing ([POST] /v1/listings/{id}/publish)
6. Listing Verification is triggered automatically

Step 3 — Retrieve Official Permit Details

• Endpoint: [GET] /v1/compliances/{permitNumber}/{licenseNumber}
• Required Parameters:
  • permitType
  • permitNumber
  • licenseNumber (company license number)
• Purpose: Retrieve latest official DLD permit data to ensure that the listing aligns with official records.
• Why: Prevent discrepancies in critical fields like price, location, and property type. Any discrepancies between your listing and the DLD data can lead to listing rejection or legal complications.

DLD Listing Type Enforcement

From the compliance response, extract data[].property.listingType.

This value defines the official property classification and must be mapped to a valid type when creating a listing.

Mapping: listingType → allowed listing type values

Example:

If DLD listingType = "Unit", valid listing type values include: "Apartment", "Duplex", "Penthouse", etc.

DLD Sale Type Enforcement

From the [GET] /v1/compliances/{permitNumber}/{licenseNumber} response, extract data[].property.saleType.

This value indicates the market type of the property (primary or secondary market) and should be used to determine the listing's projectStatus field.

• Primary: First sale from developer (primary market)
• Secondary: Resale property (secondary market)
• Empty string: Sale type not specified by DLD - any projectStatus can be selected

Mapping: saleType → projectStatus values

Example:

If DLD saleType = "Primary" and property is under construction, set projectStatus to off_plan_primary. If DLD saleType = "Secondary" and property is ready, set projectStatus to completed. If DLD saleType = "" (empty), you may select any appropriate projectStatus based on the property's actual state.

Step 4 — Create Listing

• Use retrieved permit data to populate all regulated fields.
• Ensure that the listing type matches the value allowed by the DLD listingType

Best Practices

• Always use the most recent data obtained from the compliance endpoint to populate your listing.
• Avoid manual alterations to critical fields like price or property type without first updating them with the DLD and retrieving the new permit details.
• Ensure that all mandatory fields are accurately filled to prevent listing rejections.

Ongoing Maintenance and Updates

• Price or Detail Changes: Before making any changes to listing details via the API, ensure the information is first updated with the DLD. Once updated, use the GET /v1/compliances/ endpoint to retrieve the latest permit details and then update your listing accordingly.
• Regular Verification: Periodically verify that your listings remain consistent with DLD records, especially if there are changes in regulations or property details.

ABU DHABI

In Abu Dhabi, compliance is handled under the Abu Dhabi Real Estate Center (ADREC).
ADREC enforces the presence and validity of the ADREC permit before listings can go live.

Special Business Rules

• ADREC compliance is mandatory for listings in Abu Dhabi.
• Client type must be one of: broker, property_management, or developer.
• Sub-permit rules apply: if the given permit has sub-permits, the correct sub-permit must be provided in the request. Only one (sub)permit can be used per live listing.
• Listing verification must be applied manually after creation, with supporting documents provided.

ADREC Offering Type Enforcement

This indicates the offering type and must align with ADREC Permit Type

Mapping: Permit Type → listing data

Example:

If ADREC Permit Type = "Sale", the listing offering type must be sale.

Validation

• Error message/action: example error detail: "Offering type check failed. Expected sale, got rent"
• How to avoid failure: Always derive category from the ADREC permit Permit Type, and keep them in sync when creating or updating the listing

Property Types and Amenities by Category

Property Types and Amenities by Category

Property Types and Amenities by Category

Property Types and Amenities by Category

Property Types and Amenities by Category

GET /v1/listings

• added the optional property 'results/items/rnpm' to the response with the '200' status

POST /v1/listings

• added the optional property 'rnpm' to the response with the '200' status

PUT /v1/listings/{id}

• added the optional property 'rnpm' to the response with the '200' status

POST /v1/listings/{id}/rnpm/enable

• endpoint added

POST /v1/listings/{id}/rnpm/revoke

• endpoint added

GET /v1/listings/{id}/upgrades

• added the new optional 'query' request parameter 'includeBundles'

GET /v1/wallets/balance

• endpoint added

GET /v1/listings/{id}/publish/prices

• removed the non-success response with the status '400'

POST /v1/listings

• added the optional property 'media/images/items/original/error' to the response with the '200' status
• added the optional property 'media/images/items/watermarked/error' to the response with the '200' status

PUT /v1/listings/{id}

• added the optional property 'media/images/items/original/error' to the response with the '200' status
• added the optional property 'media/images/items/watermarked/error' to the response with the '200' status

GET /v1/listings

• added the optional property 'results/items/media/images/items/original/error' to the response with the '200' status
• added the optional property 'results/items/media/images/items/watermarked/error' to the response with the '200' status

POST /v1/listings

• !WARNING! removed the request property 'media/images/items/large'
• !WARNING! removed the request property 'media/images/items/medium'
• !WARNING! removed the request property 'media/images/items/original/height'
• !WARNING! removed the request property 'media/images/items/original/width'
• !WARNING! removed the request property 'media/images/items/thumbnail'
• !WARNING! removed the request property 'media/images/items/watermarked'

PUT /v1/listings/{id}

• !WARNING! removed the request property 'media/images/items/large'
• !WARNING! removed the request property 'media/images/items/medium'
• !WARNING! removed the request property 'media/images/items/original/height'
• !WARNING! removed the request property 'media/images/items/original/width'
• !WARNING! removed the request property 'media/images/items/thumbnail'
• !WARNING! removed the request property 'media/images/items/watermarked'

GET /v1/users

• DEPRECATED: The callTracking field in the User response is now deprecated and will always return null
  • This field previously returned call tracking phone numbers for users
  • The field remains in the response schema for backwards compatibility but will be removed in a future version
  • Integrations should stop relying on this field and remove any logic that depends on call tracking data

POST /v1/webhooks

• added the new 'listing.action' enum value to the request property 'eventId'

Webhook Events

• Enhanced documentation for listing.action webhook event
  • Added comprehensive overview explaining compliance and quality action notifications
  • Documented all 24 action types with categorization (DLD permits, ADREC permits, REGA permits, verification, agent licenses, quality, transactions)
  • Detailed status lifecycle: pending, dispute_created, expired
  • Documented expiration reasons: RESOLVED, ACTION_TIMEOUT, DISPUTE_ACCEPTED, DISPUTE_REJECTED, DANGLING_PARENT
  • Added practical examples for DLD permit mismatch and incomplete location scenarios
  • Documented expire actions: listing_unpublish, revalidate_permit
  • Updated schema to specify type field must be listing.action
  • Improved field descriptions with client-focused language
  • Updated example values to be more realistic

GET /v1/listings

• !WARNING! added the new '21' enum value to the 'results/items/bedrooms' response property for the response status '200'
• !WARNING! added the new '21' enum value to the 'results/items/compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '22' enum value to the 'results/items/bedrooms' response property for the response status '200'
• !WARNING! added the new '22' enum value to the 'results/items/compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '23' enum value to the 'results/items/bedrooms' response property for the response status '200'
• !WARNING! added the new '23' enum value to the 'results/items/compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '24' enum value to the 'results/items/bedrooms' response property for the response status '200'
• !WARNING! added the new '24' enum value to the 'results/items/compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '25' enum value to the 'results/items/bedrooms' response property for the response status '200'
• !WARNING! added the new '25' enum value to the 'results/items/compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '26' enum value to the 'results/items/bedrooms' response property for the response status '200'
• !WARNING! added the new '26' enum value to the 'results/items/compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '27' enum value to the 'results/items/bedrooms' response property for the response status '200'
• !WARNING! added the new '27' enum value to the 'results/items/compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '28' enum value to the 'results/items/bedrooms' response property for the response status '200'
• !WARNING! added the new '28' enum value to the 'results/items/compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '29' enum value to the 'results/items/bedrooms' response property for the response status '200'
• !WARNING! added the new '29' enum value to the 'results/items/compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '30' enum value to the 'results/items/bedrooms' response property for the response status '200'
• !WARNING! added the new '30' enum value to the 'results/items/compliance/regaResponse/bedrooms' response property for the response status '200'

POST /v1/listings

• !WARNING! added the new '21' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '21' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '22' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '22' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '23' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '23' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '24' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '24' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '25' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '25' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '26' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '26' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '27' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '27' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '28' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '28' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '29' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '29' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '30' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '30' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• added the new '21' enum value to the request property 'bedrooms'
• added the new '22' enum value to the request property 'bedrooms'
• added the new '23' enum value to the request property 'bedrooms'
• added the new '24' enum value to the request property 'bedrooms'
• added the new '25' enum value to the request property 'bedrooms'
• added the new '26' enum value to the request property 'bedrooms'
• added the new '27' enum value to the request property 'bedrooms'
• added the new '28' enum value to the request property 'bedrooms'
• added the new '29' enum value to the request property 'bedrooms'
• added the new '30' enum value to the request property 'bedrooms'

PUT /v1/listings/{id}

• !WARNING! added the new '21' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '21' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '22' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '22' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '23' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '23' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '24' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '24' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '25' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '25' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '26' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '26' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '27' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '27' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '28' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '28' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '29' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '29' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• !WARNING! added the new '30' enum value to the 'bedrooms' response property for the response status '200'
• !WARNING! added the new '30' enum value to the 'compliance/regaResponse/bedrooms' response property for the response status '200'
• added the new '21' enum value to the request property 'bedrooms'
• added the new '22' enum value to the request property 'bedrooms'
• added the new '23' enum value to the request property 'bedrooms'
• added the new '24' enum value to the request property 'bedrooms'
• added the new '25' enum value to the request property 'bedrooms'
• added the new '26' enum value to the request property 'bedrooms'
• added the new '27' enum value to the request property 'bedrooms'
• added the new '28' enum value to the request property 'bedrooms'
• added the new '29' enum value to the request property 'bedrooms'
• added the new '30' enum value to the request property 'bedrooms'

GET /v1/listings

• added the optional property 'results/items/compliance/issuingClientLicenseNumber' to the response with the '200' status
• added the optional property 'results/items/compliance/regaResponse/compliance/issuingClientLicenseNumber' to the response with the '200' status

POST /v1/listings

• added the new optional request property 'compliance/issuingClientLicenseNumber'
• added the optional property 'compliance/issuingClientLicenseNumber' to the response with the '200' status
• added the optional property 'compliance/regaResponse/compliance/issuingClientLicenseNumber' to the response with the '200' status

PUT /v1/listings/{id}

• added the new optional request property 'compliance/issuingClientLicenseNumber'
• added the optional property 'compliance/issuingClientLicenseNumber' to the response with the '200' status
• added the optional property 'compliance/regaResponse/compliance/issuingClientLicenseNumber' to the response with the '200' status

GET /v1/locations

• added the new optional 'query' request parameter 'filter[parent]'

GET /v1/leads

• !WARNING! for the 'query' request parameter 'perPage', the max was decreased from '100.00' to '50.00'
• added the required property 'data/items/listing/reference' to the response with the '200' status

GET /v1/users/

• added the new optional 'query' request parameter 'email'
• added the new optional 'query' request parameter 'id'

GET /v1/credits/transactions

• endpoint added

GET /v1/credits/balance

• endpoint added

WHPayloadLead

• added reference field to listing object

GET /v1/leads

• added the new optional 'query' request parameter 'projectId'

POST /v1/webhooks

• added the new 'listing.published' enum value to the request property 'eventId'
• added the new 'listing.unpublished' enum value to the request property 'eventId'

Webhooks

• added the new 'listing.published' event
• added the new 'listing.unpublished' event

POST /v1/listings

• the request property 'media/images/items/large' was deprecated
• the request property 'media/images/items/medium' was deprecated
• the request property 'media/images/items/thumbnail' was deprecated
• the request property 'media/images/items/watermarked' was deprecated
• !WARNING! the request property 'media/images/items/original' became required
• !WARNING! the request property 'media/images/items/original/url' became required

PUT /v1/listings/{id}

• the request property 'media/images/items/large' was deprecated
• the request property 'media/images/items/medium' was deprecated
• the request property 'media/images/items/thumbnail' was deprecated
• the request property 'media/images/items/watermarked' was deprecated
• !WARNING! the request property 'media/images/items/original' became required
• !WARNING! the request property 'media/images/items/original/url' became required

POST /v1/webhooks

• added the new 'publicProfile.verification.approved' enum value to the request property 'eventId'
• added the new 'publicProfile.verification.rejected' enum value to the request property 'eventId'

PATCH /v1/users/{id}

• the request property 'password' was deprecated

POST /v1/listings/{id}/unpublish

• endpoint added

GET /v1/leads

• added the optional property 'data/items/responseLink' to the response with the '200' status

GET /v1/listings/{id}/publish/prices

• endpoint added
• This new endpoint allows to retrieve the publishing price for listings.

POST /v1/public-profiles/{id}/submit-verification

• endpoint added

GET /v1/stats/public-profiles

• endpoint added

GET /v1/listings

• Added: filter[advertisementNumber] in query - This allows filtering of listings by advertisement number (DTCM/RERA)

Authorization API endpoints

User API endpoints

Roles API endpoints

Listing API endpoints