ImmobilienScout24 Data Scraper & Authorized ImmoScout24 Data Workflows

ImmobilienScout24 Property Data Starts With the Access Model

ImmobilienScout24 is now branded ImmoScout24. Scout24 announced the brand change in 2019, while the former name remains common in searches and industry references.

Scout24 describes ImmoScout24 as its platform for residential and commercial real estate in Germany.

NenoData should approach this source as an authorization-first data workflow using approved real-estate data workflows, not as a generic crawl-any-page scraping project.

A useful ImmoScout24-related project needs to answer:

• Which property entities or records are required?
• Is the requirement rental, purchase, or both?
• Which German pricing components need separate fields?
• Does the customer already have official API or user-authorized access?
• Is the planned use permitted by the relevant ImmoScout24 agreement?
• Which fields and endpoints are available for that approved use case?
• How long may the returned data be stored?
• What output will the downstream system need?

Those questions matter because ImmoScout24 offers an official API, but API availability is not equivalent to unrestricted data rights.

What ImmoScout24 Property Data May Be Relevant?

The exact field set depends on the approved API resource, licence, customer authorization, page/source type, and use case.

This is an illustrative requirements model, not guaranteed ImmoScout24 field coverage. Fields must be confirmed against the actual authorized API resource, customer-controlled data, licence, or other approved source before implementation.

Kaltmiete, Warmmiete, and Nebenkosten Should Not Become One Generic Rent Field

A German rental dataset may need to distinguish:

• Kaltmiete — source-stated base/cold rent
• Nebenkosten — separately stated ancillary/service costs
• Heizkosten — heating costs where separately supplied
• Warmmiete / Gesamtmiete — broader source-stated monthly rental amount
• Kaution — deposit
• Kaufpreis — purchase asking price

Illustrative normalized fields might include:

• · cold_rent_eur
• · ancillary_costs_eur
• · heating_costs_eur
• · warm_rent_eur
• · deposit_eur
• · purchase_price_eur

For example:

These are illustrative transformation examples only. Do not automatically derive one rent component from another unless the approved source semantics and transformation rule support it.

NenoData’s Data Cleaning & Standardization service supports field-level rules, schema mapping, validation, exception handling, and preserving unresolved values for review rather than silently rewriting them.

Keep Rental and Purchase Pricing Semantically Separate

The schema should not mix:

• Kaltmiete
• Warmmiete
• Nebenkosten
• Kaufpreis
• deposits
• price per square metre

Potential fields include:

• · transaction_type
• · purchase_price_eur
• · cold_rent_eur
• · warm_rent_eur
• · ancillary_costs_eur
• · heating_costs_eur
• · deposit_eur
• · price_per_sqm

A monthly rental amount and purchase asking price are not variants of one generic field.

Normalize Wohnfläche, Grundstückfläche, and Zimmer Without Losing Meaning

Useful distinctions include:

• Wohnfläche
• Grundstückfläche
• Zimmer
• Wohnung/Haus
• Baujahr
• energy-related attributes where supplied

Normalize formatting but retain source meaning. Values that cannot be transformed safely should remain unchanged or move to exception review. Do not translate away useful German source terminology in the underlying data model if retaining the source value improves traceability.

ImmoScout24 Has an Official API

ImmoScout24 provides official developer APIs using OAuth 1.0a. See the official authentication documentation for details.

Applications use a consumer key and consumer secret.

Some endpoints support two-legged OAuth.

User-specific resources generally require three-legged OAuth, where the relevant ImmoScout24 user authorizes the application.

The existence of these mechanisms does not grant unrestricted access to all marketplace data.

The current official authentication documentation confirms OAuth 1.0a, consumer key/secret usage, and the distinction between two-legged and three-legged authorization. User-specific resources require the user to grant permission, and each resulting access token belongs to that authorizing user.

Search and Expose APIs Are Not General Bulk Data Feeds

Official ImmoScout24 documentation states that the Search APIs are for content partners and are not intended for general data-delivery use cases.

The Expose APIs carry the same content-partner restriction and require appropriate permission.

Expose resources use three-legged OAuth in the documented workflow.

Therefore NenoData should not describe the official API as a public bulk-listings API.

The current official Search and Expose documentation explicitly states these content-partner and data-delivery limitations.

Website Crawling Is Expressly Restricted

Current published ImmoScout24 API Terms prohibit crawler, robot, spider, screening, and similar technologies from being used to obtain information from the ImmoScout24 website or database. See the ImmoScout24 API Terms of Use.

This is not merely a technical anti-bot issue.

The current API Terms state that a licensee may not use crawling, robots, spiders, screening, or other technologies to access the ImmoScout24 website or database in order to obtain information.

API Access Also Has Storage and Usage Restrictions

API access should not be described as a licence to build an unrestricted independent property database.

The published general API Terms state that API rights are limited to the applicable use contract.

They also contain restrictions on creating the licensee’s own databases or evaluations and include a 24-hour storage limitation for retrieved data under the stated general provision.

A customer’s specific contract, paid-use arrangement, booking, cooperation agreement, content-partner agreement, or separate licence may contain different rights and therefore needs to be reviewed before a project is defined.

Current ImmoScout24 terms state that only explicitly granted rights apply, that other purposes including creation of the licensee’s own databases or evaluations are impermissible under the general provision, and that the right to store retrieved ImmoScout24 data is limited to one day under that provision. Separate written agreements can contain deviating terms.

Do not promise:

• indefinite retention
• generic historical warehousing
• independent price-analysis databases
• unrestricted redistribution
• permanent archive creation
• unrestricted downstream reuse

Authorized ImmoScout24 Data Paths NenoData Can Evaluate

NenoData’s data sources overview covers alternative approved property-data inputs subject to source, page-type, visible-field, geography, feasibility, and permitted-method review. Multi-source aggregation supports mapping agreed external and customer-authorized sources into a common schema.

What If the Requirement Is Market Analysis?

Define the information requirement first. That may include:

• rental asking prices
• purchase asking prices
• Wohnfläche
• Zimmer
• price per m²
• property categories
• selected energy fields
• location

Those fields can form a business schema without assuming ImmoScout24 grants the required analysis rights.

If the ImmoScout24 licence does not permit the planned analytical use, evaluate licensed datasets, customer inventory, brokerage exports, valuation feeds, or other approved property sources. Do not treat a commercially useful use case as evidence that the relevant ImmoScout24 agreement permits it.

One-Time Data and Historical Monitoring Require Different Rights

A one-time approved data workflow and a historical listing archive are not equivalent.

Potential history fields include:

• · observed_at
• · first_seen_at
• · last_seen_at
• · previous asking price
• · current asking price
• · source status

Historical retention must only be offered where the customer’s specific source rights permit it. Do not claim that NenoData already maintains an ImmoScout24 history database. Do not imply that the general API Terms permit indefinite historical retention. See also: Rental Market Data Scraping Services for broader recurring-observation context.

Delivery Depends on Source Rights

Broader NenoData services support:

• CSV
• Excel
• JSON
• API-ready payloads
• database loads
• warehouse loads
• scheduled delivery

For ImmoScout24-derived data, the customer’s source agreement determines whether any particular output, retention pattern, or downstream use is permitted. Technical delivery capability does not override source rights. NenoData’s Custom Data Pipelines service supports validated delivery to files, APIs, databases, warehouses, and BI tools from approved public or permissioned sources.

How an Authorized ImmoScout24 Data Project Would Work

1. 1

   Define the business requirement

   Specify the rental/purchase/commercial use case, target markets, required fields, history requirement, intended use, and destination.

2. 2

   Confirm access and rights

   Identify the official API, customer-user authorization, content-partner status, separate licence, customer-owned data, or alternative approved sources. Review endpoint, storage, retention, and downstream-use conditions.

3. 3

   Define the schema

   Map Kaltmiete, Warmmiete, Nebenkosten, Heizkosten, Kaution, Kaufpreis, Wohnfläche, Grundstückfläche, Zimmer, property type, location, and energy fields.

4. 4

   Integrate through the approved path

   Use only the permitted API, feed, export, licensed source, or other approved mechanism. Website crawler circumvention is not the implementation path.

5. 5

   Normalize and validate

   Apply approved rules for EUR fields, German number formatting, rent components, square metres, room counts, transaction types, property types, nulls, identifiers, and exceptions.

6. 6

   Deliver within the permitted rights

   Prepare only the output, retention model, and destination supported by both the project scope and source agreement.

Potential Business Requirements

Do not imply that an ImmoScout24 licence automatically permits every one of these use cases.

Why NenoData Is Relevant

NenoData’s broader property and data-quality services focus on:

• source and field scoping
• schema mapping
• normalization
• validation
• exception handling
• structured output
• alternative-source aggregation
• delivery into approved downstream systems

For ImmoScout24, the correct workflow is:

requirements analysis → access and rights review → approved API/source → German property schema → normalization → validation → permitted delivery

rather than crawler bypass.

NenoData Is Not Affiliated With ImmoScout24 or Scout24

No affiliation, endorsement, partnership, official API relationship, or content-partner status is claimed. Do not use ImmoScout24 branding, logos, or language in a way that visually suggests otherwise.

Frequently Asked Questions