Aziz API
Overview
Partner catalogue of Dubai off-plan and ready properties, with end-client application intake.
Aziz Catalogue API 1.0.0
Section titled “Aziz Catalogue API 1.0.0”The Aziz Catalogue API provides read access to projects, units and developers, together with a single write operation: an end client’s application for a specific unit.
Getting an API key
Every operation requires an agency API key. Keys are issued by the agency itself on the Aziz platform, estate.azizdubai.com; this API only verifies them.
- Use an agency account. API keys are available to agency (broker) companies only. Developer companies do not have access to this feature.
- Obtain the permission. The user issuing the key must hold the API keys permission. Company owners have it by default; for any other role, the company owner grants it under Roles & permissions.
- Issue the key. Sign in to
estate.azizdubai.com and, in the
API keys section of the agency account, create a key and provide:
name— a label identifying the integration (for example,CRM integration);price_vector— optional; the markup (positive) or discount (negative) in percent applied to every price served under this key. It must be greater than-100and no greater than100. The default is0, which means list prices.
- Store the key securely. The key (
azk_followed by 64 hexadecimal characters) is displayed once only, at creation. Aziz stores only its SHA-256 hash and cannot display it again. If a key is lost, revoke it and issue a new one. - Verify the key. Call
GET /whoIAm. The response confirms the key, the company that owns it, the user who issued it and the price factor applied to its prices.
The key’s name, price vector and status can be changed in the same
section. A revoked or deleted key is rejected with 401 on the next
request. The user who issues a key is recorded as the author of every
application submitted with it.
In Swagger UI, select Authorize and paste the key to try the operations below.
Authentication
Send the key in the X-API-Key header or as
Authorization: Bearer <key>. It is required on every operation; a
request without a valid key receives 401. In addition to granting
access, the key determines pricing: its price_vector is applied to
every price in the response and, in reverse, to the bounds of price
filters.
Domain restriction
A key can be restricted to a list of domains. When the list is set, a
request is accepted only if the host of its Origin header (or, if
Origin is absent, its Referer header) exactly matches one of the
listed domains; subdomains must be listed individually. Requests that
carry neither header are rejected. A request that fails this check
receives 403 origin is not allowed for this api key. A key without a
domain list is not restricted.
Agency licence and developer contracts
A key belongs to an agency, and the agency must hold an approved
licence: until it does, every operation answers
403 agency license is required: upload a company license and wait for its approval.
The catalogue a key sees consists only of developers the agency has
an approved contract with. Other developers, their projects and units do
not exist for the key: they are absent from GET /companies,
GET /projects and GET /projects/list, and GET /projects/{id},
GET /projects/{id}/contacts, GET /units/{id} and
POST /units/{id}/applications answer 404 for them.
The only routes that do not require a key are service routes not described in this specification: the CORS preflight and this documentation itself.
Files
This service does not serve files; it only returns links to them. A
url is STATIC_BASE_URL followed by the full stored path, and the
link is served by an external host (a static server, a CDN or the main
backend).
Response envelope
Every response is either { "status": "success", "data": … } or
{ "status": "error", "message": "…" }. The schemas below describe the
complete envelope.
Field naming
Field names are in snake_case, with one exception: GET /units/{id}
returns the underlying data model as is, so the nested project.company
and project.author objects use PascalCase keys (CompanyName,
Email), as do the project’s own CreatedAt and UpdatedAt. The
schemas below reflect the response exactly.
Detailed explanations and examples are available in docs/api/*.md in
the repository.
Authentication
Section titled “Authentication”apiKeyHeader
Section titled “apiKeyHeader”The agency API key in plain text. See “Getting an API key” above for how to obtain one.
Security scheme type: apiKey
Header parameter name: X-API-Key
bearerKey
Section titled “bearerKey”The same key sent as Authorization: Bearer <key>. A bare value
without a scheme is also accepted; any other scheme is ignored, in
which case X-API-Key is read instead.
Security scheme type: http