Daft.ie Property Data Starts With the Access Path
Daft.ie is operated by Daft Media Limited and is part of Distilled, the Irish marketplace group that also owns DoneDeal.ie and Adverts.ie. (Daft About page)
For a property-data team, the useful first question is not simply: “Can we scrape Daft.ie?” It is: “Does Daft’s official API or another authorized commercial path already support this requirement?”
A useful project should define:
- sale, rental, sharing, commercial, short-term, new-development, or parking scope
- target counties, cities, areas, or postcodes
- property types
- search-result versus detail requirements
- BER fields
- floor area and price-per-m² requirements
- location/Eircode requirements
- selling method where relevant
- listing dates and lifecycle fields
- one-time versus recurring need
- intended use
- API/customer access
- downstream destination
NenoData’s current Real Estate Data Scraping service scopes projects around required sources, markets, fields, update schedules, intended use, and destinations before implementation, with source support and field availability confirmed rather than assumed.
Daft.ie Has an Official API
Daft currently publishes official V3 API documentation. Its stated purpose is to expose a subset of Daft.ie property data to third-party developers, including commercial users such as Daft estate-agent clients building their own property-search applications.
The API uses:
This makes Daft materially different from source pages where no first-party API can be verified.
The existence of the API does not establish unrestricted marketplace export rights.
How Do You Get a Daft API Key?
Current API documentation says every request requires an API key. For users of agent accounts, Daft instructs them to contact their Daft.ie account manager for an API key.
The documentation also exposes permission/authentication failure states where:
- an account is not enabled
- privileges are insufficient
- an API key is invalid
- a request originates from a network not agreed with Daft support
The API must therefore not be positioned as an unrestricted anonymous or self-service bulk marketplace export.
Before designing an integration, confirm:
- whether the customer has a Daft commercial/account relationship
- whether credentials already exist or can legitimately be requested
- which endpoints or operations are enabled
- intended use
- relevant categories
- field coverage
- storage rights
- retention
- downstream-use rights
NenoData must not claim it already holds the customer’s API key.
The Official API Covers Several Property Categories
Current V3 documentation lists dedicated search functions for:
It also documents:
Not every parameter or operation is publicly available to every API user. Current documentation marks some search parameters as available only to Daft employees.
The official API exists and exposes a documented subset of property data; exact coverage and permissions must be confirmed for the customer’s account.
Do not imply that every authenticated account receives identical access.
Official Daft API vs Third-Party “Daft API”
Third-party products may market themselves as:
A third-party “Daft API” is not the same as the official first-party Daft API.
Official Daft API
- first-party
- API key required
- SOAP over HTTP / XML
- account and permission dependent
- subset of Daft property data
- agent-account access path
- employee-only parameters exist
Third-party scraper API
- external vendor
- technical extraction service
- not official Daft authorization
- does not establish Daft permissions
- rights must be assessed separately
| Access type | Provider | What it means |
|---|---|---|
| Official Daft API | Daft.ie | First-party authenticated API subject to Daft account access and permissions |
| Third-party scraper API | External vendor | Technical extraction product, not official Daft authorization |
| Customer-owned feed/export | Customer/agency | Rights depend on customer ownership and agreements |
| Licensed commercial source | Approved provider | Governed by separate licence/contract |
Evaluate the official Daft API first where it fits the requirement.
What Daft.ie Data May Be Relevant?
The exact schema depends on the approved API/source, listing category, account permissions, and engagement scope.
Illustrative schema. Exact fields depend on the approved API/source and account permissions.
Ad Type
Sale
Rental
Sharing
Commercial
New Development
Short-term
Parking
Price
asking price
rent
EUR
€/m²
Property
type
bedrooms
bathrooms
floor area
BER
rating
BER number/code
performance value
Location
county
city
area/postcode
Eircode where supplied
Observation
listed date
observed_at
first_seen
last_seen
| Data category | Potential fields | Qualification |
|---|---|---|
| Listing identity | Daft ID, source URL, ad type, listing status | Source dependent |
| Pricing | asking sale price, rent, EUR, price per m² | Preserve listing-price semantics |
| Property | property type, bedrooms, bathrooms, floor area, site/plot fields where supplied | Category dependent |
| Energy | BER rating, BER number/code, energy-performance value where supplied | Never infer missing values |
| Location | address, area, county, city, postcode, Eircode/coordinates where supplied | Access/source dependent |
| Sales context | selling method, sale-agreed status | Where supplied |
| Rental context | availability, lease length, furnishing, rent collection period, rental attributes | Where supplied |
| Publisher | agent/agency identity where permitted | Personal/contact fields require separate review |
| Lifecycle | listed date, observed_at, first_seen, last_seen | Repeated retrieval/retention must be permitted |
| Source metadata | API/source ID, category, source URL | Useful for provenance |
This is an illustrative requirements schema. It is not a guarantee that every Daft property, listing category, or API account exposes every field.
Sale, Rental, Sharing, Commercial, and New Developments Need Different Schemas
Daft’s API itself demonstrates that these categories have materially different semantics.
Sale
- asking price
- bedrooms
- bathrooms
- property/house type
- sale-agreed status
- BER
- selling method
- listing age/date
Rental
The API documentation includes rental-specific concepts such as availability, lease length, and furnishing.
- asking rent
- rent collection period
- available date
- lease length
- furnishing
- features
- bedrooms
- bathrooms
Sharing
Sharing records contain room/occupancy-level concepts that should not be flattened into whole-property rental semantics.
Short-term
Short-term records can contain different occupancy and availability concepts from ordinary rental records.
Parking
Parking should remain a distinct ad/category type rather than being forced into a residential property schema.
New developments
New-development records can contain project/development semantics rather than ordinary second-hand listing semantics.
NenoData’s Rental Market Data Scraping service supports approved-source rental workflows where source availability is confirmed during scoping.
A normalized master schema is possible, but ad_type and category-specific fields must remain explicit.
BER Is a First-Class Irish Property Field
Ireland’s Building Energy Rating (BER) is one of the most useful source-specific concepts for Daft property data.
Source fields (potential)
- BER rating
- BER code/certificate number
- energy-performance indicator
Schema fields
- ber_rating
- ber_number
- energy_performance_value
- energy_performance_unit
- ber_exempt where actually supplied by the approved source
- ber_observed_at
- Do not infer missing BER.
- Do not generate a BER class from unrelated fields.
- Do not convert an absent field into a rating.
- Do not treat an estimated energy value as automatically equivalent to the source BER class.
NenoData’s Data Cleaning & Standardization service supports BER field mapping, transformation rules, and validation.
BER Data Can Support More Than Search
Where appropriately sourced, BER information may support:
Keep BER within a source-aware property model:
listing → property → BER → location → observation
Keep BER within a source-aware property model rather than treating BER as detached enrichment with no provenance.
Asking Price Is Not a Completed Transaction Price
A Daft sale listing is a marketplace advertisement. The source price should therefore remain an advertised/marketplace observation. It must not automatically become:
A suitable schema may include:
asking_price_eurasking_price_per_sqm_eurtransaction_price_eur from an appropriate separate sourceprice_sourceobserved_atIf completed transaction information is required, use a separately approved transaction/property-record source and keep provenance distinct.
Price per m² Should Preserve Its Basis
Where price per m² is source-provided, store it separately from total asking price.
If NenoData derives it, make the calculation explicit: asking price ÷ agreed floor-area field. Only derive it when:
- the correct price field is known
- the correct area value is known
- the correct area basis is known
- the calculation rule is agreed
Do not derive it from:
- site/plot area
- an ambiguous area field
- a missing/estimated value without an explicit rule
Irish Floor Area and Commercial Area Need Unit Context
Area values must preserve: numeric value, source unit, area type/basis where known, normalized value, and normalized unit.
Current Daft API documentation uses square-foot parameters for some commercial searches. If downstream analysis standardizes square feet to square metres, preserve both:
- Do not silently convert or overwrite the source representation.
- Do not use an ambiguous area value for €/m² calculations.
Eircode and Location Data Should Remain Source-Dependent
Irish property workflows may need:
The official API supports geographic/location searching, including:
Current documentation also includes Northern Irish postcode examples. That does not establish universal Eircode or coordinate availability for every property record.
Use: where supplied through the approved API/source.
Do not:
- invent Eircodes
- infer exact coordinates
- manufacture address precision
- claim every record contains an Eircode
Selling Method Should Be Separate From Listing Status
Current Daft API documentation exposes concepts such as selling type/method and sale-agreed status. Where available, preserve fields such as:
selling_methodlisting_statussale_agreed_statusExamples of selling method may include:
Do not merge commercial sale method with lifecycle status. A listing can have:
- a selling method
- a separate availability/sale-agreed state
- separate observation timestamps
Daft’s Website Terms Explicitly Restrict Automated Retrieval
Daft’s current Terms prohibit use of:
The current Terms also prohibit using access/retrieval/indexing for the purpose of constructing or populating a database.
Current Terms further restrict website-content uses such as:
Treat this as an access/content-rights boundary. Do not position:
The correct decision path is:
official API / commercial access / written permission / customer-owned source / another approved source
Daft Also Supports Professional Data Use Under Defined Terms
Daft’s advertiser terms Daft’s advertiser terms demonstrate that professional and commercial data-related products can exist under defined contractual conditions.
Daft’s Valuation Tool is a professional product that provides certain clients access to live and historical Daft listing information for property comparison, analysis, and valuation use cases.
Treat this as evidence that legitimate professional data use may exist through specific products and agreements.
Do not treat it as evidence that:
- ordinary website crawling is permitted
- NenoData has Valuation Tool access
- NenoData can redistribute its data
- NenoData owns historical Daft listing data
- every advertiser receives identical data rights
If the Valuation Tool wording remains current, preserve its product-specific restrictions, including restrictions on competing use, redistribution, and automated/screen-scraping activity.
Authorized Daft.ie Data Paths NenoData Can Evaluate
Daft.ie publishes an official API, while direct website retrieval and database-building are restricted by its current Terms.
Need Daft.ie property data
Does the official Daft API fit the use case?
Yes
Confirm API access
API key / account permissions
Confirm category + field coverage
Define schema
Normalize + validate
Permitted delivery
No direct API
Alternative paths
Explicit Daft authorization
Customer-owned agency inventory
Approved agency feed
Licensed Irish property source
Other approved source
Official Daft API
Where the customer has or can obtain appropriate API access, NenoData can scope API integration, authentication using customer-provided credentials, enabled operation review, category handling, source-to-target mapping, BER mapping, location handling, normalization, validation, and approved destination delivery. NenoData must not claim it already holds the API key.
Daft-approved commercial access
If the customer has another documented Daft relationship, permission, or commercial product entitlement, scope the project strictly around those rights. Confirm fields, categories, storage, retention, internal versus external use, public display, redistribution, and cadence.
Customer-owned estate-agency inventory
Estate agencies may already control their own property listings, prices, BER data, images, internal CRM records, and listing status. NenoData can normalize customer-controlled data without implying broader Daft marketplace rights.
Approved estate-agent feeds
Customer-authorized feeds/exports can be mapped into a common Irish property schema.
Customer-provided files
Potential inputs include CSV, Excel, JSON, CRM exports, database extracts, and listing-management exports.
Licensed Irish property datasets
Where the official Daft API does not fit the requirement, evaluate an appropriate licensed or otherwise approved Irish property source.
Other approved Irish property sources
A business requirement can be re-scoped to another licensed, public where appropriate, permissioned, or customer-authorized source.
Multi-source property intelligence
Where several approved inputs are required, map them into a common schema with source attribution, schema normalization, matching, deduplication, validation, and exception handling.
NenoData’s Multi-Source Data Aggregation service supports agreed external and customer-authorized sources rather than arbitrary source use.
NenoData’s Data Sources page explicitly treats source feasibility and permitted collection method as scoping questions rather than guarantees.
The page must remain commercially useful when official Daft API access does not fit.
Agent and Contact Data Need Separate Review
Daft API documentation includes agent-related functionality, and listings can expose agency or contact context. That does not make personal contact information unrestricted data.
Daft’s current Terms contain restrictions around collection/use of information concerning other users and require applicable data-protection obligations to be respected.
Do not make these a headline proposition:
Any use of personal/contact information requires separate review of:
One-Time Dataset or Recurring Daft Observations
Where the approved API/source arrangement permits repeated retrieval and retention, a workflow may use a snapshot or recurring observation model.
One-time requirements
- Irish housing-market research
- rental analysis
- BER analysis
- agency-inventory integration
- investment research
- internal BI
- data migration
Recurring observations
Potential observation fields:
- observed_at
- first_seen
- last_seen
- asking price
- rent
- listing status
- sale-agreed status
- listing date
- BER where source-visible
Current API documentation includes search concepts such as listing age, sale/rental agreed status, and edit/update-related parameters. Some update-related parameters are permission restricted.
Do not infer recurring rights merely because a technical field exists. Repeated access and retention must be confirmed for the customer’s approved arrangement.
Do not claim:
- an existing NenoData Daft archive
- historical NenoData coverage
- daily refresh by default
- hourly refresh
- real-time refresh
- a fixed Daft-specific SLA
Delivery Must Fit the Approved Daft Access Arrangement
NenoData’s Custom Data Pipelines service can support:
- CSV
- Excel
- JSON
- API-ready records
- database loads
- warehouse loads
- webhooks
- scheduled workflows
For each Daft-related project, confirm:
- 1.source/API access
- 2.enabled categories
- 3.enabled operations
- 4.permitted fields
- 5.storage
- 6.retention
- 7.transformation
- 8.internal versus external use
- 9.personal-data treatment
- 10.redistribution/public display
- 11.destination
- 12.cadence
“API-ready” means NenoData can prepare records for downstream programmatic consumption. It does not mean NenoData owns or resells an unrestricted Daft marketplace API.
How an Authorized Daft.ie Data Workflow Would Work
- 1
Define the requirement
Specify property/ad categories, Irish geography, search versus detail requirements, required fields, BER requirements, Eircode/location requirements, one-time versus recurring need, intended use, and downstream destination.
- 2
Evaluate official API access first
Confirm current Daft account/commercial relationship, API-key availability, enabled operations, account permissions, category coverage, field coverage, and downstream-use conditions.
- 3
Select the approved source path
Potential routes include official Daft API, explicit Daft permission, another Daft commercial product/arrangement, customer-owned agency inventory, approved agency feed, licensed Irish property source, customer-provided files, or another approved Irish source.
- 4
Define the category-specific schema
Preserve ad type, listing identity, asking price/rent, category-specific property attributes, BER, floor area/unit, location, selling method, status, listing dates, and source identifiers.
- 5
Normalize units and values
Apply agreed rules for EUR, price per m², source area units, normalized area units, property types, bedrooms/bathrooms, selling method, BER, and location fields.
- 6
Validate
Check required fields, allowed values, missing BER, source IDs, duplicates, ambiguous location, area/unit consistency, source attribution, and exception cases.
- 7
Review downstream rights
Confirm internal use, public display, storage, retention, redistribution, privacy, destination, and recurring access.
- 8
Deliver
Prepare the approved CSV, Excel, JSON, API-ready records, database, warehouse, webhook, or scheduled/recurring output.
Potential Business Requirements
These are buyer requirements, not evidence that every use is automatically permitted by Daft.
Irish housing-market analysis
Structure approved sale records by geography, property type, asking price, BER, and floor area.
Rental-market analysis
Normalize approved rent, rent period, bedrooms, furnishing, availability, location, and observation fields.
BER and energy research
Preserve source-visible BER values for energy-performance segmentation. Do not infer missing BER values.
Estate-agent integrations
Where the customer’s Daft/API relationship supports it, map approved property inventory into internal websites, applications, analytics systems, and operational workflows.
Listing monitoring
Track permitted asking-price changes, status changes, sale-agreed changes, and listing availability where recurring retrieval and retention are approved.
Investment research
Prepare appropriately sourced Irish property records for internal screening.
PropTech applications
Map approved Irish property records into search, enrichment, analytics, and internal product schemas.
Multi-source Irish property intelligence
Combine Daft-authorized inputs, customer-owned property data, and other approved Irish property sources within a common source-aware schema.
Why NenoData Is Relevant to a Daft.ie Requirement
Real Estate Data Scraping
- source/access review
- market and field scoping
- custom property schemas
- normalization
- validation
- timestamps
- structured delivery
Rental Market Data Scraping
- approved public or permissioned rental-source workflows
- rent and availability fields
- listing and structured delivery where scoped
Data Cleaning & Standardization
- schema mapping
- transformations
- validation
- deterministic deduplication
- exception review
- CSV, Excel, JSON, API-ready outputs
AI Entity Resolution and Matching
- scoped matching with defined identifiers/fields
- representative record testing
- review paths for ambiguity
Multi-Source Data Aggregation
- agreed external sources
- customer-authorized inputs
- common schemas
- matching, deduplication, source attribution
Custom Data Pipelines
- files, API-ready records, databases, warehouses
- webhooks and scheduled processes
- approved source-to-destination workflows
Data Sources
- source availability confirmed during scoping
- field coverage confirmed rather than assumed
- permitted collection method as a scoping question
For Daft.ie, preserve:
requirements → official API/access review → approved source → Irish property/BER schema → normalization → validation → permitted delivery
not unrestricted Daft.ie scraping.
NenoData Is Not Affiliated With Daft.ie or Distilled
NenoData does not claim affiliation with Daft.ie, partnership with Daft Media Limited, partnership with Distilled, official Daft API credentials, a Daft agent account, unrestricted marketplace rights, Valuation Tool access, an existing Daft dataset, historical Daft coverage, or authorized-scraper status. Only state such a relationship if separately documented.
Frequently Asked Questions
A Daft.ie scraper generally refers to software or a workflow intended to turn Daft property information into structured records. For NenoData, that term must not imply unrestricted website crawling. The official Daft API should be evaluated first where applicable.
A Daft.ie scraper generally refers to software or a workflow intended to turn Daft property information into structured records. For NenoData, that term must not imply unrestricted website crawling. The official Daft API should be evaluated first where applicable.
Yes. Daft currently publishes a first-party API that exposes a subset of Daft.ie property data to third-party developers.
Yes. Daft currently publishes a first-party API that exposes a subset of Daft.ie property data to third-party developers.
Current documentation says every request requires an API key. Users of agent accounts are instructed to contact their Daft.ie account manager.
Current documentation says every request requires an API key. Users of agent accounts are instructed to contact their Daft.ie account manager.
No such assumption should be made. Current documentation includes permission-based restrictions and parameters/functions that are not available to ordinary public developers.
No such assumption should be made. Current documentation includes permission-based restrictions and parameters/functions that are not available to ordinary public developers.
Current V3 documentation includes: sale, rental, commercial, new development, short-term, sharing, and parking.
Current V3 documentation includes: sale, rental, commercial, new development, short-term, sharing, and parking.
Potentially, where supplied through the approved Daft API/source. BER should remain source-displayed and must not be inferred when missing.
Potentially, where supplied through the approved Daft API/source. BER should remain source-displayed and must not be inferred when missing.
Potentially, where the approved source supplies it. Do not guarantee Eircode availability for every record.
Potentially, where the approved source supplies it. Do not guarantee Eircode availability for every record.
Yes. They should use category-specific pricing, status, lifecycle, and property-field semantics.
Yes. They should use category-specific pricing, status, lifecycle, and property-field semantics.
No assumption should be made that they are. Marketplace prices should remain advertised/asking values unless an appropriate separate source confirms a completed transaction.
No assumption should be made that they are. Marketplace prices should remain advertised/asking values unless an appropriate separate source confirms a completed transaction.
Current Terms prohibit robots, spiders, search/retrieval applications, and other automated means used to retrieve or index the website and prohibit use of the site to construct or populate a database. The Terms also restrict scraping/mirroring and related content reuse without express written permission.
Current Terms prohibit robots, spiders, search/retrieval applications, and other automated means used to retrieve or index the website and prohibit use of the site to construct or populate a database. The Terms also restrict scraping/mirroring and related content reuse without express written permission.
Where the customer’s approved Daft/source rights permit it, NenoData’s broader services can support CSV, Excel, JSON, API-ready records, databases, warehouses, webhooks, and scheduled delivery. Technical delivery capability does not create Daft source rights.
Where the customer’s approved Daft/source rights permit it, NenoData’s broader services can support CSV, Excel, JSON, API-ready records, databases, warehouses, webhooks, and scheduled delivery. Technical delivery capability does not create Daft source rights.
No. They are third-party extraction products and must not be confused with Daft’s first-party API.
No. They are third-party extraction products and must not be confused with Daft’s first-party API.
Daft advertiser terms describe professional products that can provide certain clients with live/historical listing-data functionality for defined professional uses. That does not establish NenoData access or unrestricted reuse rights.
Daft advertiser terms describe professional products that can provide certain clients with live/historical listing-data functionality for defined professional uses. That does not establish NenoData access or unrestricted reuse rights.
Only where the customer’s approved API/source arrangement permits repeated retrieval and retention. No NenoData-owned Daft historical archive or fixed refresh cadence is promised.
Only where the customer’s approved API/source arrangement permits repeated retrieval and retention. No NenoData-owned Daft historical archive or fixed refresh cadence is promised.
Agency identity may be usable where permitted. Personal phone, email, owner/user, or lead information requires separate source-rights, necessity, privacy, retention, and intended-use review.
Agency identity may be usable where permitted. Personal phone, email, owner/user, or lead information requires separate source-rights, necessity, privacy, retention, and intended-use review.
Potential alternatives include official Daft API, Daft-approved commercial access, customer-owned agency inventory, approved estate-agent feeds, licensed Irish property datasets, customer-provided files, and other approved Irish property sources.
Potential alternatives include official Daft API, Daft-approved commercial access, customer-owned agency inventory, approved estate-agent feeds, licensed Irish property datasets, customer-provided files, and other approved Irish property sources.
No affiliation, partnership, endorsement, official API relationship, or authorized-scraper status is claimed.
No affiliation, partnership, endorsement, official API relationship, or authorized-scraper status is claimed.