Netherlands short-term rental regulation and SDEP status

What this means

The Netherlands provides the strongest public example of a national short-term rental data-sharing interface currently visible.

For platforms and software vendors, the Dutch implementation shows the expected direction of travel: authenticate as a platform, discover regulated areas, submit structured activity data, and let competent authorities retrieve data through authority-facing endpoints.

National implementation has moved from adoption to enactment: both chambers adopted the amending law implementing Regulation (EU) 2024/1028 (Tweede Kamer 18 June 2026, Eerste Kamer 7 July 2026), the law was enacted on 8 July 2026 and the implementing decree on 31 August 2026, and a commencement decree sets entry into force at 1 November 2026, with the data-sharing provisions applying from 1 July 2026.

Implementation status

The public documentation describes SDEP Netherlands as a gateway for electronic transmission of short-term rental data between online short-term rental platforms and competent authorities.

The implementation separates platform-facing STR endpoints from competent-authority CA endpoints. Platforms use the STR API to retrieve regulated-area information and submit activity data. Competent authorities use the CA API to manage regulated areas and retrieve activity data relevant to their scope.

Regulated areas are operationally important. Authorities can publish area information, including geospatial boundary data, and platforms may need to match rental addresses or geometries to an area identifier before submitting activity data.

Technical interface

Public API documentation is available at sdep.gov.nl/api/docs. The current page presents Common, Auth v1, stable STR v1, and Netherlands-specific AMA v1, CA v1, and STA v1 surfaces.

The Auth API exposes token-based machine-to-machine authentication. The public reference implementation uses OAuth2/OIDC with JWT bearer tokens, role-based access for platform and competent-authority operations, and one OAuth 2.0 Client Credentials grant with client-secret and client-signed-JWT authentication methods.

The STR API includes regulated-area discovery and bulk activity submission for platform-side reporting. The CA API includes area registration, area retrieval/deactivation, activity retrieval, activity counts, and shapefile exchange. The AMA and STA APIs provide read-only activity-monitoring and statistics access to activity data, counts, competent authorities, and platforms; the earlier REP v1 surface is no longer published.

The current public application version is 1.10.0 across the live Common, Auth v1, CA v1, STR v1, AMA v1, and STA v1 OpenAPI documents, with unchanged path sets. Version 1.9.0 moved previously draft design items into stable STR v1: regulated-area retrieval is limited to 1000 records per call, activity timestamps must be UTC, activity is rejected for listing-only areas, listing URLs are accepted up to 2048 characters, full addresses up to 328 characters, and registration numbers up to 128 characters. It also made functional identifiers owner-scoped, so an areaId, listingId, or activityId submitted by another party is refused as duplicate_error. Version 1.9.1 refuses non-string identifiers in bulk writes instead of returning a server error. Version 1.10.0 makes activity submission idempotent, so the same records sent again after a network failure do not create duplicates; this uses deterministic identifiers rather than random ones, versioning with the same identifier still produces a new version, and the release states no change to the v1 contract. The documentation page still presents stable EU-harmonised STR v1 plus country-specific AMA v1, CA v1, and STA v1, and the previously documented CA v2, REP v1, and STR v2 URLs still return 404.

SEMICeu SDEP issues opened in May 2026 flag address/fullAddress validation edge cases, a Eurostat capacity-indicator gap, licence-dependent registration-number lifecycle questions, activity-data validation clarifications, and optional-activity-ID versioning concerns.

SDEP activity data is stay/flow data, so stock and capacity metrics may need registration or national-register data as well. Recent SEMICeu issue discussion points to host registration data such as maximum bed places and guest capacity as a likely source for Eurostat stock indicators, with duplicate handling needed when the same unit is offered on more than one platform. Platform connectors should persist returned SDEP activity IDs and treat idempotency/versioning as first-class reporting state.

The public SEMICeu SDEP repository describes a FastAPI/PostgreSQL/Keycloak implementation with Docker Compose and a pre-production environment for integration partners. Recent changelog entries add security hardening, JWT verification and audit-log improvements, malware scanning support, safer upload/download handling, an API versioning policy, CA v2 activity filters, a read-only REP v1 reporting/statistics API, a production-suitable smoke test, PostgreSQL utility targets, OAuth 2.0 JWT Client Authentication support, a bulk-activity duplicate-owner bugfix, an optional areaName field in activity responses, a 1.4.1 docs/operations follow-up, and the 1.5.0 removal of the filter prefix from CA v2 and REP v1 query parameters, plus the 1.9.0/1.9.1 owner-scoped identifier rule and its v1 backports, and the 1.10.0 change that makes resubmission idempotent so retried records do not duplicate. The 15 September listing-regulation proposal records agreement to proceed with selected changes for address length, listing URLs, UTC timestamps, pagination, area-regulation checks, and registration-number length; those items are now shipped in stable v1.

The API versioning policy distinguishes the URL-path API contract version from the semantic application version. Breaking contract changes should introduce a new API version, while additive optional fields/endpoints can remain on the same version.

The repository README distinguishes the EU-harmonised STR component from the CA component, which is guidance/recommendation and may differ by Member State.

SEMICeu SDEP issue updates confirm that /str/areas is intended to return regulated areas only, and that platforms are not obliged to transmit data to a Member State before its SDEP is operational.

Recent SEMICeu SDEP issue activity tracks whether activity timestamps should be UTC-only, whether listing URL limits should move toward 2048 characters, whether platform-provided activity IDs should become mandatory for safer versioning, whether STR area discovery should default to paginated retrieval at large-country scale, how SDEPs should handle bulk activity submissions for areas that do not require activity reporting, and how one address maps to one or several registration units/listings. The 1.2.0 public update adds CA v2 filters for incremental authority-side activity retrieval, issue #82 raises richer platform identity information for competent authorities, and issue #90 raises the separate room-versus-unit modelling question.

Registration workflow

Hosts register a dwelling through the national registration scheme and receive a digital registration number; platforms must let hosts add it to listings and validate the information randomly.

Platforms use the STR API to discover regulated areas before submitting activity data.

Competent authorities use the CA API to register, retrieve, and deactivate regulated areas.

Regulated-area matching is a key operational step because submissions may need an area identifier tied to geospatial boundaries.

Technical interfaces

Common API: health/basic operations including ping.

Auth v1: token endpoint for machine-to-machine authentication, with client-secret and client-signed-JWT authentication methods within the OAuth 2.0 Client Credentials flow.

STR v1: regulated-area discovery and bulk activity submission; the v2 constraints on UTC timestamps, listing-only areas, and 1000-record area pages now also apply in stable v1.

CA v1: activity retrieval, activity counts, area management, and shapefile exchange.

CA v2: the same CA area path set plus activity retrieval/count query filters for UTC created-at range, platform ID, and area ID.

REP v1: read-only reporting/statistics activity retrieval and activity counts, gated by a reporting role in the reference implementation, with filters for UTC created-at range, platform ID, area ID, and competent-authority ID.

Reference implementation stack: FastAPI, PostgreSQL, SQLAlchemy async, Alembic, Pydantic, Keycloak OAuth2/OIDC, and Docker Compose.

The REP v1 OpenAPI surface adds reporting/statistics endpoints while preserving the existing Common/Auth/CA/STR path sets; the public version metadata is PRD-1.6.0 across the visible v1/v2 surfaces. Beta STR v2 adds UTC-only timestamps, listing-only area rejection, and 1000-record area pagination. CA v2 and REP v1 use the unprefixed createdAtFrom, createdAtTo, platformId, areaId, and (for REP) competentAuthorityId query parameters.

Issue discussion and the 1.3.1/1.4.x updates point toward stricter v2/client behaviour: stable platform activity IDs, UTC-only timestamps for created-at filters, production private-key/JWT onboarding, longer listing URLs, paginated regulated-area discovery with a 1000-record default/page size, and richer activity responses that now optionally echo areaName.

Recent SDEP issue activity highlights two platform-side validation concerns: area-list retrieval should be paginated and cached for large deployments, and activity submissions should check whether the selected regulated area actually requires activity reporting before personal data is sent.

Public SDEP issues previously asked how platforms should represent listings with no completed or cancelled stay; the reference implementation answered this on 25 September 2026 by confirming that activity data contains only listings with stays and that Eurostat data has to be derived from the national register. A stay/activity submission is therefore not an all-listings registration-compliance feed. A separate question remains open on what should count as one registration unit when one address can map to several separately offered rooms.

Open questions

How registration-number validation and local Dutch registration/licensing workflows connect to SDEP Netherlands.

Whether capacity or stock metrics will require separate registration or national-register datasets in addition to SDEP activity data, how consistently Member States expose host-declared bed-place and guest-capacity fields for reporting use, and how cross-platform duplicate units are identified for statistics.

How Member States and SDEP implementations will handle activity-data edge cases such as unknown guest countries, UTC/time-zone rules, long stays, long listing URLs, and versioning when platforms omit activity IDs.

How quickly national deployments adopt versioned CA-side and reporting-office additions such as CA v2 filters and REP v1 read-only reporting, and whether platform-facing STR v2 changes follow later.

Whether mandatory pagination, 2048-character listing URLs, UTC-only timestamp validation, mandatory platform activity IDs, and area-regulation-based submission/data-minimisation handling become v1 behaviour, v2 changes, or national implementation guidance.

How the specification will define a unit for registration and reporting when whole properties and individual rooms at the same address can be advertised separately.