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.

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 visible API surfaces are Common, Auth v1, CA v1, STR v1, CA v2, and REP v1.

The Auth API exposes token-based machine-to-machine authentication. The public reference implementation uses OAuth2/OIDC with JWT bearer tokens and role-based access for platform and competent-authority operations.

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 new REP API is read-only and exposes activity data and counts for statistics/reporting-office use cases across competent authorities and platforms.

The current public OpenAPI version string is PRD-1.3.1 across Common, Auth v1, CA v1, STR v1, CA v2, and REP v1 documentation. Existing Common/Auth/CA/STR/CA v2/REP v1 visible paths remain stable; CA v2 and REP created-at filters require UTC date-time values, and REP v1 remains the read-only activity retrieval and activity-count surface for reporting and statistics.

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 metrics may need registration or national-register data as well. 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, and PostgreSQL utility targets.

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, and how SDEPs should handle bulk activity submissions for areas that do not require activity reporting, including GDPR/security concerns about unnecessary personal-data retention. The 1.2.0 public update adds CA v2 filters for incremental authority-side activity retrieval, and issue #82 raises richer platform identity information for competent authorities.

Registration workflow

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.

STR v1: regulated-area discovery and bulk activity submission.

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.3.1 across all visible OpenAPI surfaces.

Issue discussion and the 1.3.1 update point toward stricter v2/client behaviour: stable platform activity IDs, UTC-only timestamps for created-at filters, longer listing URLs, and paginated regulated-area discovery with a 1000-record default/page size.

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.

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 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.