Formatos de importación

Skautik lee los formatos que el sector ya usa, así que en la mayoría de los casos envías lo que ya le mandas a un portal inmobiliario y no cambias nada más.

De un vistazo

OpenImmo

El estándar del sector en alemán, y el formato que casi cualquier CRM germanoparlante ya sabe producir.

Región Alemania, Austria, Suiza
Codificación XML 1.2.7, UTF-8, dentro de un ZIP
Entrega Entrega por SFTP, o subir el ZIP a la API
Identificador de ficha verwaltung_techn / objektnr_extern

Una transferencia es un ZIP que contiene un documento XML y las imágenes que este referencia por nombre de archivo. El XML lleva un bloque anbieter por proveedor y un bloque immobilie por inmueble. Leemos la familia 1.2.x y aceptamos los documentos 1.1 más antiguos que algunos sistemas siguen emitiendo.

Cómo funciona la retirada

Explícita. Cada inmueble lleva un elemento aktion cuyo aktionart es CHANGE o DELETE, así que una transferencia dice qué quitar en lugar de dejarlo a la deducción.

Imágenes

Las imágenes viajan dentro del ZIP y se referencian por nombre de archivo en elementos anhang. El orden sigue el orden del documento, y la primera imagen pasa a ser la principal salvo que se marque otra.

Ejemplo

<?xml version="1.0" encoding="UTF-8"?>
<openimmo>
  <uebertragung art="OFFLINE" umfang="TEILZUGRIFF"
                modus="NEW" version="1.2.7"
                sendersoftware="YourCRM" />
  <anbieter>
    <anbieternr>AG-4471</anbieternr>
    <immobilie>
      <objektkategorie>
        <nutzungsart WOHNEN="true" />
        <vermarktungsart KAUF="true" />
        <objektart><wohnung wohnungtyp="DACHGESCHOSS" /></objektart>
      </objektkategorie>
      <geo>
        <plz>10999</plz>
        <ort>Berlin</ort>
        <strasse>Oranienstrasse</strasse>
      </geo>
      <preise><kaufpreis>429000</kaufpreis></preise>
      <flaechen>
        <wohnflaeche>74</wohnflaeche>
        <anzahl_zimmer>3</anzahl_zimmer>
      </flaechen>
      <freitexte>
        <objekttitel>Dachgeschosswohnung mit Balkon</objekttitel>
      </freitexte>
      <anhaenge>
        <anhang location="INTERN" gruppe="BILD">
          <anhangtitel>Wohnzimmer</anhangtitel>
          <daten><pfad>wohnzimmer.jpg</pfad></daten>
        </anhang>
      </anhaenge>
      <verwaltung_techn>
        <objektnr_extern>AG-4471-0812</objektnr_extern>
        <aktion aktionart="CHANGE" />
      </verwaltung_techn>
    </immobilie>
  </anbieter>
</openimmo>

Conviene saber

• anzahl_zimmer es un recuento de estancias según la convención alemana y suele incluir el salón. Lo mapeamos a estancias, y no deducimos habitaciones a partir de él.
• Una transferencia marcada como TEILZUGRIFF es una actualización parcial y nunca implica que los inmuebles ausentes deban retirarse. Solo VOLLZUGRIFF se trata como una sustitución completa.
• Los precios son brutos o netos según los campos presentes. Leemos los campos de precio tal como se envían en lugar de derivar uno del otro.

RESO Web API

El estándar MLS moderno. Si tus datos vienen de un MLS con una Web API certificada, esta es la vía con menos mapeo.

Región Estados Unidos, Canadá
Codificación OData 4.0 sobre JSON, Data Dictionary 1.7 o posterior
Entrega Recogemos de tu endpoint de forma programada
Identificador de ficha ListingKey

Tú aportas la raíz del servicio y las credenciales, y nosotros replicamos el recurso Property, siguiendo Media y OpenHouse donde estén expuestos. Como el Data Dictionary ya estandariza los nombres de campo y las enumeraciones, el mapeo es en gran medida automático.

Cómo funciona la retirada

Por estado, no por eliminación. Un anuncio cuyo StandardStatus sale del conjunto activo se retira por nuestro lado; las fichas no se borran, así que el historial sobrevive.

Imágenes

Se leen del recurso Media y se recogen por URL. MediaModificationTimestamp nos permite volver a recoger solo lo que ha cambiado en lugar de todas las imágenes en cada pasada.

Ejemplo

GET /Property?$filter=ModificationTimestamp gt 2026-08-11T04:00:00Z
       &$orderby=ModificationTimestamp
       &$expand=Media
       &$top=200

{
  "@odata.context": "…/$metadata#Property",
  "value": [
    {
      "ListingKey": "MLS-88213004",
      "StandardStatus": "Active",
      "ListPrice": 429000,
      "LivingArea": 796,
      "LivingAreaUnits": "Square Feet",
      "BedroomsTotal": 2,
      "City": "Austin",
      "StateOrProvince": "TX",
      "ModificationTimestamp": "2026-08-11T09:14:22Z"
    }
  ]
}

Conviene saber

• La replicación es incremental sobre ModificationTimestamp. Solapamos la ventana entre pasadas, porque de otro modo una ficha confirmada un instante después de un corte se perdería para siempre.
• LivingAreaUnits se respeta en lugar de suponerse. Un feed en pies cuadrados se convierte una vez al importar, no se trata en silencio como métrico.
• Los campos locales fuera del Data Dictionary se conservan pero no se mapean, ya que su significado es específico de un MLS.

RETS

Soportado para feeds que aún no han pasado a la Web API, y tratado como una vía de migración y no como un destino.

Región Estados Unidos, heredado
Codificación RETS 1.7.2, consultas DMQL2
Entrega Recogemos de tu servidor RETS de forma programada
Identificador de ficha El campo de identificador único del MLS

RETS es anterior al Data Dictionary, así que los nombres de campo son propios de cada MLS y requieren un mapeo explícito que construimos contigo una vez. Todo lo demás de la importación se comporta igual.

Cómo funciona la retirada

Por campo de estado, como con la Web API. Algunos servidores exponen las fichas borradas solo a través de una consulta aparte, que usamos donde exista.

Imágenes

Se recogen mediante GetObject, una llamada por anuncio, lo que hace que las importaciones RETS sean más lentas que una recogida equivalente por Web API.

Conviene saber

• RETS se está retirando en todo el sector. Pásate a la Web API cuando tu MLS la ofrezca: el trabajo de mapeo desaparece y las importaciones se vuelven bastante más rápidas.
• Los nombres de campo, las enumeraciones e incluso los formatos de fecha varían por MLS, así que un conector RETS se configura individualmente en lugar de automáticamente.

BLM

El formato de carga masiva del Reino Unido. Casi cualquier CRM de agencia británica sabe emitirlo, lo que suele convertirlo en el camino más corto para meter inventario británico.

Región Reino Unido
Codificación Texto delimitado, por secciones, normalmente con un ZIP de imágenes
Entrega Entrega por SFTP, o subir a la API
Identificador de ficha AGENT_REF

Un archivo .blm se divide en secciones #HEADER#, #DEFINITION# y #DATA#. La línea de definición nombra las columnas, así que el formato se describe a sí mismo y el orden de columnas no hay que acordarlo por adelantado.

Cómo funciona la retirada

Por marca. PUBLISHED_FLAG a 0 retira un inmueble. Que una ficha simplemente desaparezca de un archivo posterior no la retira, porque de otro modo una exportación truncada borraría el inventario de una agencia.

Imágenes

Se referencian por nombre de archivo en las columnas MEDIA_IMAGE_00 a MEDIA_IMAGE_NN, con los archivos aportados junto al fichero.

Ejemplo

#HEADER#
Version : 3
EOF : '^'
EOR : '~'

#DEFINITION#
AGENT_REF^ADDRESS_1^TOWN^POSTCODE1^POSTCODE2^PRICE^
PUBLISHED_FLAG^BEDROOMS^PROP_SUB_ID^MEDIA_IMAGE_00~

#DATA#
BR-10024^12 Oranien Street^London^SE1^4TX^650000^
1^2^1^BR-10024-01.jpg~

#END#

Conviene saber

• La cabecera declara sus propios separadores de campo y de registro. Los leemos del archivo en lugar de suponer el circunflejo y la tilde convencionales.
• PROP_SUB_ID codifica el tipo de inmueble como un número cuyo significado lo fija la especificación, no quien envía.
• Los precios son libras enteras. Un archivo que ha pasado por una hoja de cálculo y ha adquirido decimales se rechaza en lugar de redondearse.

Kyero XML

Un esquema pequeño y legible, muy usado para inventario residencial internacional, y fácil de emitir desde un sistema que no tiene una exportación específica de inmuebles.

Región España, Portugal y anuncios internacionales
Codificación Feed XML, versión 3
Entrega Recogemos la URL de tu feed de forma programada
Identificador de ficha id

Un solo documento contiene todos los inmuebles, con precios, un tipo, componentes de ubicación y descripciones por idioma. Su sencillez es lo importante: un feed completo es fácil de generar y de verificar a ojo.

Cómo funciona la retirada

Implícita. El feed es una declaración completa del inventario actual, así que todo lo ausente en una recogida correcta se retira. Es el único formato en el que la ausencia significa retirada.

Imágenes

Se referencian por URL en elementos image, cada uno con un id que fija el orden de presentación.

Ejemplo

<?xml version="1.0" encoding="UTF-8"?>
<root>
  <kyero><feed_version>3</feed_version></kyero>
  <property>
    <id>4471-0812</id>
    <date>2026-08-11 09:14:22</date>
    <ref>AG-4471-0812</ref>
    <price>429000</price>
    <currency>EUR</currency>
    <price_freq>sale</price_freq>
    <type>Apartment</type>
    <town>Marbella</town>
    <province>Malaga</province>
    <country>Spain</country>
    <beds>2</beds>
    <baths>1</baths>
    <surface_area><built>74</built></surface_area>
    <images>
      <image id="1"><url>https://example.com/1.jpg</url></image>
    </images>
  </property>
</root>

Conviene saber

• Como la ausencia significa retirada, una recogida fallida o truncada podría borrar tu inventario. Rechazamos un feed que haya encogido más de una proporción configurable, y avisamos en su lugar.
• price_freq distingue un precio de venta de un periodo de alquiler. Omitirlo hace el precio ambiguo, y rechazamos en lugar de adivinar.

CSV

El recurso cuando no encaja nada más. Todos los sistemas saben producir una hoja de cálculo, y un mapeo convierte los nombres de tus columnas en los nuestros.

Región En cualquier sitio
Codificación RFC 4180, UTF-8, separado por comas
Entrega Subir a la API, entrega por SFTP o una URL que recogemos
Identificador de ficha columna external_id

Aporta una fila de cabecera y mapéala una vez; el mapeo se guarda en la fuente de importación y se reutiliza. Solo external_id y un puñado de columnas fundamentales son obligatorias, y cualquier columna que no tengas puede sencillamente faltar.

Cómo funciona la retirada

Por columna. Una columna de estado puesta a withdrawn retira un inmueble. La ausencia nunca retira nada, porque una exportación parcial es demasiado fácil de producir sin querer.

Imágenes

Una o más columnas con URL de imagen, o nombres de archivo si además aportas un ZIP.

Ejemplo

external_id,title,transaction_type,property_type,price,currency,
living_area,bedrooms,street,postal_code,city,country,status,image_urls
AG-4471-0812,Top-floor apartment,sale,apartment,42900000,EUR,
74,2,Oranienstrasse,10999,Berlin,DE,active,"https://…/1.jpg|https://…/2.jpg"

Conviene saber

• El dinero es un entero en unidades menores, igual que en el resto de la API. 42900000 con EUR son 429.000,00. Equivocarse en esto por un factor de cien es el error más común en CSV, así que una pasada en seco informa del precio más alto y del más bajo que ha leído para que lo revises.
• Las columnas con varios valores usan una barra vertical, porque una coma dentro de un campo CSV es un problema de entrecomillado esperando a ocurrir.
• Un archivo cuya cabecera no coincida con su mapeo guardado se rechaza entero en lugar de aplicarse a medias.

JSON nativo

Nuestro propio esquema, sin ninguna capa de mapeo. La elección correcta cuando controlas el sistema que exporta.

Región En cualquier sitio
Codificación NDJSON o un array JSON, ajustado al esquema de inmueble
Entrega Subir a la API, o enviar fichas de una en una por POST
Identificador de ficha external_id

Las fichas coinciden con el objeto property que devuelve la API, con external_id añadido para que podamos casar las tuyas con las nuestras. NDJSON es preferible para cualquier cosa grande, ya que se transmite en flujo en lugar de exigir el documento entero en memoria.

Cómo funciona la retirada

Por campo de estado, o llamando a DELETE directamente sobre el inmueble.

Imágenes

URL de imagen en un array images, recogidas después de aceptar la ficha.

Conviene saber

• Enviar POST individuales está bien para un puñado de fichas y está mal para miles: usa una importación para que todo el conjunto se valide y se aplique junto.

Algo completamente distinto

Si tu sistema exporta un formato que no está aquí, envíanos una muestra en lugar de escribir un conversor. Los formatos de intercambio inmobiliario son un conjunto pequeño y conocido, y añadir uno suele ser un día de trabajo por nuestro lado frente a semanas por el tuyo.

Empieza por importación masiva para ver cómo funciona el ciclo de vida, sea cual sea el formato que acabes usando.