Version 1.24
January, 2021
Table of Contents
INTRODUCTION
The Domibus Send Data System is organized around REST. Domibus SDS uses predictable, resource-oriented URLs, and uses HTTP POST requests. We support cross-origin resource sharing, allowing you to recieve data securely with our SDS from a client-side web application (though you should never expose your secret API key in any public website's client-side code). JSON is sent by all our requests.
This section of the documentation is geared towards developers.
REST Request - how to send a request including the domains, paths, and HTTP Method conventions we use. Also includes how to authenticate yourself.
REST Response - we have a standard response wrapped, which is detailed here. We also talk about HTTP status codes and how we return error messages.
REQUESTS
Using SSL
All requests should be called over SSL. You must use SSL when working with non-public data such as customer accounts and private information. Make sure your client/server technology supports SSL.
Data Types
Array Inputs
JSON Payloads Data is returned using JSON (Javascript Object Notation). JSON is the only format we support. It's a lightweight serialization language that is compatible with many different programming languages and technologies. JSON is syntactically correct JavaScript code, meaning you can use the Javascript eval() function to parse it.
HTTP Methods
All requests will be sent via HTTP POST, since we will be sending/creating one or more resources. However, some operation require other HTTP methods:
HTTP Method | Description |
GET | Reads resources via URL, often with query string criteria |
POST | Create a new resource. |
PATCH | Updates an existing resource. |
Authentication
Your Partner Token is provided by Domibus. Token API keys carry many privileges, so be sure to keep them secret! Do not share your secret API keys in publicly accessible areas such GitHub, client-side code, and so forth.
Authentication to your API/Webhook is performed via HTTP Shared User Token.
Each POST request needs to contain information that identifies you as the client and the agent/office.
The following variables will be included in all POST calls:
- Authorization: Bearer which is the Partner Token sent in the header. (using the parameter Authorization: Bearer TOKEN)
- agent_id which is sent as a POST variable. (Given by you in order to identify the user/agent sending real estate information)
- agent_token which is sent as a POST variable. (Given by you in order to identify the user/agent sending real estate information)
POST Request parameters V.1 (literal)
Parameter | Value | Description |
agent_id | String | The identifier of the user sending data. |
agent_token | String | The token identifier of the user sending data. |
reference | Int | The reference of the property. |
prospect | Bool | Is it a prospect? |
operacion_type | String | The type of operation being offered. Values: ('venta', 'alquiler') |
price | Int | The price of the property. |
property_type | String | The type of property being offered. Values: ('Loft','Estudio','Apartamento','Piso','Atico','Bajo','Buhardilla','Planta baja','Vivienda', 'Chalet','Chalet adosado','Chalet pareado', 'Casa','Casa de pueblo','Casa o chalet independiente','Casa adosada','Casa rural','Casa terrera','Caseron','Cortijo','Masia','Finca rustica', 'Castillo','Castillos','Torre','Torres','Mansion','Palacio','Pueblo','Villa' 'Duplex','Bungalow','Triplex', 'Oficina','Local','Local o nave','Almacén','Nave','Nave industrial', 'Garaje','Trastero','Terreno','Edificio') |
provence | String | The provence where the property is located. |
locality | String | The locality where the property is located. |
street | String | The street where the property is located. |
street_number | String | The street number where the property is located. |
lat | Float | The lattude where the property is located. |
lng | Float | The longitude where the property is located. |
bedroom | Int | The number of rooms on the property. |
wc | Int | The number of bathrooms on the property. |
m2 | Int | The area of the property. |
m2_terrain | Int | The area of the terrain of property. |
origin | String | The origin website of the property. |
url | String | The url of the property. |
description | String | The description of the property. |
features | String List | The list of features on the property. |
building | String List | The list of building features on the property. |
equipment | String List | The list of equipment features on the property. |
urban_sit | String | The urban situation of the property/terrain. |
status | String | The prospect status of the property. Values ES: ('Pendiente,'Contactado','Captado','No Contactar','No Disponible') |
first_name | String | The prospect first name of the property. |
last_name | String | The prospect last name of the property. |
phone | String | The prospect phone of the property. |
phone_alt | String | The prospect phone alternative of the property. |
String | The prospect email of the property. | |
observations | String | The prospect observations of the property. |
RESPONSE
Response Formats
All responses must be returned using JSON. JSON is a lightweight serialization language that is compatible with many different languages. JSON is syntactically correct JavaScript code, meaning you can use the Javascript eval() function to parse it.
HTTP Status Codes
Standard HTTP status codes must be used to indicate success or failure of the calls. Like with most topics, Wikipedia has good resources on HTTP Statuses, but here are the basics of what we will return:
HTTP Code | Message | Description |
200 | OK | The request was processed and returned successfully. Nothing was changed. |
201 | Created | The new resource was created successfully |
400 | Bad Request | Problem with the request, such as a missing, invalid or type mismatched parameter |
401 | Unauthorized | The request did not have valid authorization credentials |
403 | Forbidden | Private data you are not allowed to access. |
404 | Not Found | Your URL is wrong, or the requested resource doesn't exist |
429 | Too Many Requests | You've hit a rate limit. |
500 | Server Error | We call this the "crap code" error. Basically we've got a problem on our side. If this persists please contact support. We log and review all errors but your help often helps us fix it quicker. |
503 | Service Unavailable | Our API is down. Please try again. We work hard to make this rare. |
The non-20x status codes above correspond with an error of one type or another.
Errors
Errors are communicated to the client in the payload of the response.
Errors in the Response Payload
The standard response payload can contain errors. This will give more finely grained details about specific what caused the error or errors, which should allow you to respond appropriately. This might include displaying validation messages to your users, or changing the request at runtime.
Example:
{ "code": "rest_no_route", "message": "No route was found matching the URL and request method", "status": 404 }
Error Type Definition
The errors have the following data definition:
Name | Type | Description | ||
code | String | Error code. Unique string identifying the type of error. See the table below for a list of possible error codes. (Always returned) | ||
message | String | Localized user readable message describing the error. (This will be shown to the end user) | ||
status | Int | The HTTP code. |
Response Payload
Each API response is wrapped in a standard payload that contains the results of the call, plus some additional useful information and metadata.
Name | Type | Description | ||
code | String | Determines the code of the message. | ||
message | String | An explanatory description about the response. (This will be shown to the end user) | ||
status | Int | The HTTP code. |
Here's an example of a response:
{ "code": "ok", "message": "All good", "status": 200 }