# EU Bathing Water Season Records — EEA WISE (`nexgensignal/eu-bathing-water-season-records`) Actor

Keyless pay-per-record EEA WISE Bathing Water Directive season periods — bathing-water site, season year, period type and start/end dates, as filed. Site grain, no person data. Gold $0.0335/record.

- **URL**: https://apify.com/nexgensignal/eu-bathing-water-season-records.md
- **Developed by:** [NexGen Signal](https://apify.com/nexgensignal) (community)
- **Categories:** Business, Developer tools, Other
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $33.50 / 1,000 bathing-water season records

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.
Actors are written with capital "A".

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.
The best way to integrate Actors is as follows.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — the [REST API](https://docs.apify.com/api/v2.md).

For usage examples, see the [API](#api) section below.

For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt).

# README

## EU Bathing Water Season Records — EEA WISE

**Keyless. Pay per record. When each European bathing water's official season starts and ends.**

This actor turns the **European Environment Agency (EEA) WISE Bathing Water Directive (BWD) database** into clean, per-record data — the official bathing-SEASON start and end dates for Europe's bathing waters, by site and year. Each run reads the EEA's keyless DiscoData SQL service and delivers one row per season period, structured for tourism, public-health and operations analysis, reusable with acknowledgement of the EEA, with no personal data of any kind.

### What this is, in one paragraph

Every official bathing water has a declared bathing season — the window during which it is monitored and its quality is managed. This actor reads that seasonal-period table and delivers one record per site-season: the bathing-water identifier, the season year, the period TYPE, and the season START and END DATES — all carried as filed. It is the season-calendar layer of Europe's bathing-water reporting, distinct from the water-quality classification.

### Who buys this and for what job

- **Tourism platforms and travel products** showing when each beach or lake is officially in season.
- **Public-health and operations teams** aligning sampling and signage with the declared season.
- **Climate researchers** tracking whether bathing seasons are lengthening over time.
- **Data engineers** who want the BWD seasonal-period table as clean rows from a keyless source.

### EEA licence — reuse with acknowledgement

One licence rider travels on every record. EEA data may be **reused, including commercially, provided the source is acknowledged**: "Source: European Environment Agency (EEA)." Where third-party content is marked, it keeps its own terms. These are reported dates as filed — not a schedule of this actor's making.

### Site grain — no person data

The unit of every record is a season period for a bathing-water site — a site code and a date window, never a person. BWD reporting is at site level: there is **no contact or named-individual field** in the selected columns, and none is emitted. The bathing-water identifier is a site code, never a person. The free-text management-measures, remarks and metadata-statements fields are **EXCLUDED at field selection**. A person-key guard runs on every record as a backstop.

### A note on scale, honestly

The source table holds **389,214 rows** as verified by an exact `COUNT(*)` at build time, which matches the planning index for this category exactly. It spans bathing-water sites and the seasons reported for each — a long time series per site. The live count above is authoritative.

### Pricing

| Event | Free plan | Bronze | Silver | Gold / Platinum / Diamond |
|-------|-----------|--------|--------|---------------------------|
| `bathing_water_season_record` | $0.05 | $0.045 | $0.04 | $0.0335 |

Delivered before charged. Blocked runs and empty results cost nothing.

### Input

| Field | Type | Default | Description |
|-------|------|---------|-------------|
| `year` | integer | — | Optional bathing season year to filter (e.g. 2012, 2022). |
| `maxRecords` | integer | 500 | Ceiling on records delivered and billed. |

### Output

One JSON object per season period. Representative example (values as reported):

```json
{
  "record_id": "AL101:2012:2012-05-15",
  "bathing_water_identifier": "AL101",
  "season": 2012,
  "start_date": "2012-05-15",
  "end_date": "2012-09-15",
  "period_type": "bathingSeason",
  "status_code": "experimental",
  "source": "EEA WISE Bathing Water Directive (BWD) — bathing-season periods",
  "observed_at": "2026-08-27T00:00:00Z"
}
```

An unbilled `RUN_RECEIPT` records the robots check, the filters, rows seen and delivered, and whether charged equals delivered.

### Field reference

Each record is one season period. Identity: `record_id`, `bathing_water_identifier`, `season`, and `source_uid`. Season: `start_date`, `end_date`, and `period_type`. Status: `status_code`. Provenance travels on every record: `source`, `source_url`, `licence`, `attribution`, `disclaimer`, and `observed_at`.

### How a run works

A run first re-reads the source host's robots posture from your runtime — the EEA DiscoData host — and stops at the door if that ever changes. It pages the BWD seasonal-period table (filtered to your optional season `year`), ordered by the high-cardinality bathing-water identifier, and flattens each row to one record — carrying every date **verbatim**, never anything person-shaped and never the free-text fields — delivered **before** it is charged, so a blocked or empty run costs you nothing. The actor stops at your `maxRecords` ceiling and records `charge_equals_delivered` in the receipt.

### Coverage and scope

The table holds **389,214 rows** across bathing-water sites and their reported seasons. Because each record carries the `bathing_water_identifier`, the `season`, and the `start_date` / `end_date`, segmenting by site or year, or building a per-site season time series, is straightforward. Pull one season year, or the whole table to seed a bathing-water warehouse.

### Working with the data

The season windows are a calendar layer, and the fields make them actionable. Because every record gives a site a start and end date for a year, an analyst can compute season length per site, track how that length changes across years, and align quality classifications and monitoring compliance (from the sibling cells) to the exact window in which they applied.

### Season length as a signal

Because the table carries many years for each site, it is a ready-made time series of bathing-season length — a quietly useful climate and tourism signal. Subtract `start_date` from `end_date` for each record and you have the declared season length in days; group by site across years and the trend line shows whether a coast is opening earlier or closing later over a decade. The `period_type` field separates the main bathing season from any additional declared periods, so an analyst can keep the comparison clean. Because the identifier is stable across years, the series stitches together without a matching step, and because the dates are carried verbatim, the analysis rests on exactly what the member state declared — not on an inferred or smoothed calendar. Joined to the quality and monitoring-compliance cells on the same identifier, the season window also tells you which samples fell inside the official season and which did not.

### A note on identifiers

The `bathing_water_identifier` is the stable key that ties this cell to the rest of the bathing-water family. It is an official site code assigned under the Bathing Water Directive — a place, never a person — and it is the join key you use to bring season dates, quality classifications, and monitoring compliance together for a single beach or lake. Because the same identifier is used across all three cells and across every reporting year, building a complete per-site picture needs no fuzzy matching.

### Cost guidance

One `bathing_water_season_record` per delivered row: cost = rows delivered × your plan's per-record price. Scope with `year` to keep runs bounded. 1,000 rows is **$50** (Free) / **$33.50** (Gold).

### Honest limitations

- **As reported.** Season dates are as filed by member states; this actor reformats, it does not audit or recompute.
- **Long time series.** The table carries many seasons per site — filter by `year` for a single season.
- **Experimental status kept verbatim.** Some periods are flagged experimental; the status is carried through as reported.
- **Acknowledge the EEA**, and note there is **no person data** of any kind.

### Differentiation

This is a **net-new** category for the NexGenData fleet. It is the SEASON-DATES grain, a distinct source table from the live **eu-bathing-water-quality-records** (the water-quality classification) and from the monitoring-compliance cell — this cell carries the calendar, not the quality or the monitoring flags. Its specific job is the **BWD bathing-season periods**.

### The NexGen Signal family

Part of the NexGen Signal family of pay-per-record data products:

- [EU Bathing Water Quality Records — EEA](https://apify.com/nexgensignal/eu-bathing-water-quality-records)
- [EU Waterbody Quality Records — EEA](https://apify.com/nexgensignal/eu-waterbody-quality-records)
- [EU Nitrate Monitoring Records — EEA](https://apify.com/nexgensignal/eu-nitrate-monitoring-records)
- [EU Surface Water Priority Substance Records — EEA](https://apify.com/nexgensignal/eu-surface-water-priority-substance-records)
- [EU Wastewater Compliance Records — EEA UWWTD](https://apify.com/nexgensignal/eu-wastewater-compliance-records)

*Source: European Environment Agency (EEA), WISE Bathing Water Directive (BWD) database (discodata.eea.europa.eu). EEA data may be reused, including commercially, provided the source is acknowledged: "Source: European Environment Agency (EEA)"; marked third-party content keeps its own terms. Site grain; the bathing-water identifier is a site code, not a person; no contact or named-individual field is selected or emitted, no natural-person data of any kind. Reported dates as filed, not a schedule.*

# Actor input Schema

## `year` (type: `integer`):

Optional bathing season year to filter (e.g. 2012, 2022).

## `maxRecords` (type: `integer`):

Maximum records delivered and billed.

## Actor input object example

```json
{
  "maxRecords": 500
}
```

# Actor output Schema

## `results` (type: `string`):

Delivered records.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "maxRecords": 500
};

// Run the Actor and wait for it to finish
const run = await client.actor("nexgensignal/eu-bathing-water-season-records").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = { "maxRecords": 500 }

# Run the Actor and wait for it to finish
run = client.actor("nexgensignal/eu-bathing-water-season-records").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "maxRecords": 500
}' |
apify call nexgensignal/eu-bathing-water-season-records --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,nexgensignal/eu-bathing-water-season-records"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/iu8Ic9w2bdDP5KwFw/builds/osXOJuT9wRVgCkUx2/openapi.json