# GDACS Alerts Scraper - Disaster, Earthquake, Flood, Wildfire (`snow_leo_data/disaster-alerts-scraper`) Actor

776 disaster events where one GDACS query returns 100, and 704 earthquakes in 21 queries against 100. 56 fields per event. Global disaster alerts with wildfire data, tropical cyclone, drought and flood data, red and orange alert levels. UN and European Commission source.

- **URL**: https://apify.com/snow\_leo\_data/disaster-alerts-scraper.md
- **Developed by:** [Snow Leo Data](https://apify.com/snow_leo_data) (community)
- **Categories:** News, Integrations
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $0.99 / 1,000 events

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

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

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
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.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

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

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## GDACS Global Disaster Alerts - past the 100-event cap

Earthquakes, tropical cyclones, floods, volcanoes, droughts and wildfires from
GDACS, the Global Disaster Alert and Coordination System run jointly by the
United Nations and the European Commission. One row per event, 56 fields,
straight from the source.

The reason this Actor exists is a number. **A single GDACS query returns at
most 100 events, no matter how wide a window you ask for.** Ask for six years
and you get 100. Ask for a year and you get 100. Nothing in the response says
it was cut short - no total, no next page, no flag. A pipeline built on the
plain endpoint quietly stops being complete the moment the world gets busy.

This Actor splits the request by alert level, by hazard type and by date
window, halving each window again whenever it comes back full, and merges the
results by event id. You get the events, not the first hundred of them.

***

#### What exactly does this Actor collect?

Every event GDACS publishes, in six hazard types:

| Code | Hazard | What the severity number means |
|---|---|---|
| `EQ` | Earthquake | magnitude, unit `M` |
| `TC` | Tropical cyclone | maximum wind speed, unit `km/h` |
| `FL` | Flood | GDACS flood magnitude |
| `VO` | Volcano | GDACS volcanic index |
| `DR` | Drought | affected area, unit `km2` |
| `WF` | Wildfire | burnt area, unit `ha` |

Each event carries the GDACS colour - Red, Orange or Green - plus the numeric
alert score behind that colour, the countries affected, coordinates, start and
end dates, the upstream feed that produced it, and the link to the GDACS
report page a human would read.

GDACS has no separate tsunami type. Tsunami information arrives inside
earthquake events; a query for `eventlist=TS` comes back empty.

#### Why does one GDACS query return only 100 events?

Because that is the cap, and it is not documented. Measured on 2026-09-11
with plain HTTP requests, no key and no browser:

| Window asked for | Events returned |
|---|---|
| 2026-08-01 to 2026-09-12 | 20 |
| 2025-01-01 to 2026-09-11 | 100 |
| 2020-01-01 to 2026-09-11 | 100 |

Six years and twenty months give the same answer as each other, and that
answer is exactly the cap. The `live` test suite in this repository asserts
both halves of that: a wide window must come back at exactly 100, a six-week
window must come back below it. If GDACS ever raises the cap, that test fails
and the number in this README stops being true out loud rather than silently.

#### What happens if you simply ask GDACS for all three alert levels?

You lose the important ones. This is the trap that costs data rather than
time, and it is worth reading twice.

Left alone, GDACS returns Red and Orange events only - Green is absent unless
you name it. The obvious fix is to pass all three levels at once. Measured on
the window 2026-08-01 to 2026-09-12:

| Request | Events returned | Colours present |
|---|---|---|
| no `alertlevel` parameter | 20 | Red, Orange |
| `alertlevel=Green;Orange;Red` | 100 | Green only |
| `alertlevel=ALL` | 0 (empty body) | none |

Asking for everything returns a full page of green events and **drops every
red and orange event in the window**. The naive "give me all levels" call is
strictly worse than the default one. And `ALL`, the value a dropdown would
naturally send, returns an empty HTTP body - not an empty collection, an empty
body, which crashes a JSON parser that was not expecting it.

This Actor therefore queries each alert level separately and merges. That is
also why the level selector defaults to Red and Orange: those are the events
an operations desk acts on, and adding Green multiplies the volume rather than
the signal. Turn Green on when you are building an archive.

#### How much does the splitting actually recover?

Measured over 2026-01-01 to 2026-09-12, with `tools/measure_cap.py`:

- one plain query over the whole period returns **63 events**, all Red or
  Orange;
- the same query asking for all three levels returns **100** - the cap - and
  every one of them is Green;
- nine month-by-month queries over that period return 900 rows, **776 unique
  events**: 613 wildfires, 70 floods, 60 earthquakes, 25 droughts, 6 cyclones,
  2 volcanoes. All nine of those monthly queries were themselves sitting at
  the cap, so **776 is a floor, not a total**;
- the Actor's own walk halves each full window again, and reports every query
  it spent and every split it made.

Narrow it to one hazard type at one level and the gap is starker still. Green
earthquakes over 2026-08-01 to 2026-09-12, measured by the live test suite on
2026-09-12: **704 events collected in 21 queries with 10 window splits**,
against 100 from a single query. Seven times the data for twenty extra
requests.

The run report names the arithmetic so you never have to trust this paragraph:
`walk.queries`, `walk.splits`, `walk.found`, `walk.duplicates` and
`walk.cap_per_query`. Set
`compareWithSingleQuery` to true and the report also records what one plain
query would have returned over your exact window, so the comparison is made on
your data rather than on ours.

If a single day of one hazard type at one alert level still comes back full -
which can happen on a heavy wildfire day - the day is listed in
`walk.truncated_days` and logged as a warning. There is nothing left to split
at that point, and saying so is better than pretending the result is complete.

#### What do you get for each event?

Fifty-six fields. The ones that matter most:

**Identity.** `event_id` and `event_type` form the key; `episode_id` rises
every time GDACS re-issues its assessment, which is the cheapest possible
signal that a situation moved. `glide` carries the GLIDE number - the
cross-agency humanitarian identifier such as `DR-2026-000153-BLZ` - which is
how the same disaster is matched across ReliefWeb, EM-DAT and UN reporting.
`source` and `source_id` name the upstream feed and its own identifier, so an
earthquake row carries the USGS event id (`us7000tgpu`) and joins straight to
USGS data.

**Severity.** `alert_level`, `alert_score`, `episode_alert_level` and
`episode_alert_score`, plus `severity`, `severity_unit` and the sentence GDACS
writes itself in `severity_text` ("Magnitude 4.7M, Depth:61.088km").

**Place.** `country`, `iso3`, `latitude`, `longitude`, `bbox`, and
`affected_countries` - the full list with ISO2 and ISO3 for every country
GDACS attaches to the event, not just the one it is centred on. Country
filtering uses that full list.

**Time.** `from_date`, `to_date`, `date_modified`, and the `is_current` flag
GDACS uses for "still going". Dates come out in one shape across every row.

**Links.** `report_url` for the human page, plus the API links for the event
card, the polygons, the media feed and the GDACS news feed.

#### What does the event card add?

With `includeDetails` on - the default - the Actor spends one extra request per
event on the GDACS event card and fills in what the list endpoint does not
carry:

- `magnitude` and `depth_km` for earthquakes, as numbers rather than text;
- `population_exposed` and `population_exposed_text` - **GDACS's own rapid
  estimate of how many people were exposed to strong shaking**, for example
  23 526 people, worded by the source as "20 thousand (in MMI>=VII)". The
  intensity band travels with the text because GDACS varies it between
  events. This is the source's figure, not a guess made by measuring the
  distance to the nearest entry in a bundled list of cities;
- `shake_population` from the ShakeMap pass once it has run;
- `episode_count`, which tells you how many times GDACS has revised the event;
- map imagery: `overview_map_url`, `thumbnail_url`, `population_map_url`,
  `rain_map_url`.

Turn `includeDetails` off for the fastest possible listing.

#### What are the affected-area polygons?

GDACS publishes real geometry for most events: cyclone tracks, flood extents,
shaking contours, drought areas. Switch on `includeGeometry` and each row gets
a `polygons` array of GeoJSON geometries, each labelled with what it
represents. It costs one more request per event and makes rows considerably
larger, which is why it is off by default.

#### How do I watch my own sites?

Pass a list under `assets`:

```json
[
  {"name": "Manila DC",   "lat": 14.60, "lon": 120.98, "radiusKm": 300},
  {"name": "Kaohsiung port", "lat": 22.62, "lon": 120.28, "radiusKm": 500}
]
```

Every event with coordinates is measured against every site with the haversine
formula. Rows come back with `nearest_asset`, `nearest_asset_km`,
`asset_exposure` and the full `asset_matches` list, nearest first. Exposure
bands are stated rather than implied: `critical` within a quarter of your
radius, `high` within half, `moderate` within the radius. Sites outside their
radius are dropped from the list, the event itself is kept.

No geocoding service is involved and no city table is bundled, so the same
input always produces the same number. If you want a different definition of
"close", change the radius.

#### How do I only pay for what changed?

Turn on `onlyNew`. The Actor keeps a record of what it has already delivered
in a **named** key-value store, which survives between runs, and skips events
whose alert level, episode, severity, end date and ongoing flag are all
unchanged. Every row is tagged `NEW`, `UPDATED` or `UNCHANGED`.

This matters more here than in most sources, because disasters are long-lived.
A drought measured on 2026-09-11 had been running since 21 April - 143 days.
Without memory, a daily monitor pays for that one event 143 times.

Deliberately excluded from the change fingerprint: `date_modified`. GDACS
touches it whenever a model re-runs, so including it would mark nearly every
event as updated every day - which is exactly the cost the mode exists to
avoid. If you would rather have a complete snapshot each run, set
`emitUnchanged` and unchanged rows come back too, correctly tagged.

The order is always deliver first, remember second. A run that dies halfway
through has remembered no more than it actually delivered, so the next run
picks up the remainder instead of skipping it. The lifecycle test kills a run
mid-push and asserts exactly that.

#### How do I get a Slack or Discord message?

Put an incoming webhook URL in `webhookUrl` and pick a floor with
`webhookMinAlertLevel`. One message per run, listing the alerts that reached
the threshold with the GDACS report link for each, red first. A webhook that
fails is recorded in the run report and never fails the run - data first,
notification second.

#### What does the run report tell me?

It is written to the key-value store under `REPORT`:

- `walk.queries`, `walk.splits`, `walk.found`, `walk.duplicates`,
  `walk.failed_windows`, `walk.truncated_days`, `walk.cap_per_query`. The
  duplicate count is normally large and that is correct: GDACS selects events
  that *overlap* the window, so a six-month drought is returned by every
  window that touches it and is merged by event id;
- `pushed`, `by_type`, `by_alert_level`;
- `filtered_out` - how many rows each filter removed, by reason, **before**
  anything was charged;
- `changes` - the NEW / UPDATED / UNCHANGED tally in incremental mode;
- `webhook` - whether the notification went out;
- `single_query_would_return`, if you asked for the comparison.

#### How is it priced, and what is it going to cost me?

Pay per result: **$0.99 per 1,000 events**, plus Apify's usual start event.
Filters run before anything reaches the dataset, so a run that fetches 400
events and keeps 12 charges you for 12. `maxItems` is a hard stop on both rows
and spend. If you set a per-run spending limit in Apify, the Actor reads it at
start and stops itself at that number of events instead of running on at the
developer's expense.

#### How fast is it?

GDACS answers very unevenly. The same default run - twelve window queries and
fourteen event cards - finished in 28 seconds on one attempt and 175 seconds
on another, measured on the Apify platform on 2026-09-12. Per request, the
event card takes about 3.6 seconds and the polygon endpoint about 4.2 seconds.

Both stages therefore run four at a time: the window queries across hazard
type and alert level, and the event cards within each batch. Four is what
keeps a hundred-event run inside a couple of minutes even on a bad day, and is
still polite to a public service. Nothing is fired off all at once - the walk
goes a batch at a time, so a request covering years does not have to hold the
whole result in memory.

#### How does this compare with the other GDACS Actor in the Store?

There is one established GDACS Actor, and it is a serious piece of work. An
honest comparison, feature by feature, taken from its own published input
schema and dataset schema on 2026-09-11:

**Where this Actor is ahead**

- **The cap.** The reference Actor's `maxResults` tops out at 500, and its
  alert-level input is a single choice including `ALL`. This one splits the
  window until nothing is cut off, and never sends `ALL` - which, as measured
  above, returns an empty body.
- **Alert levels and hazard types are multi-select**, not one-at-a-time. You
  can ask for Red and Orange earthquakes and floods in a single run.
- **Source fields it does not expose**: `episode_id`, `episode_alert_level`,
  `episode_alert_score`, `alert_score`, `glide`, `iso3`, `bbox`,
  `polygon_label`, `icon_url`, and the whole event-card block - `magnitude`,
  `depth_km`, `population_exposed`, `shake_population`, `episode_count` and the
  map imagery - plus the affected-area polygons.
- **Population exposure comes from GDACS**, not from a bundled list of roughly
  150 cities.
- **Price**: $0.99 per 1,000 events against $2.50 per 1,000.

**Where the reference Actor is ahead, stated plainly**

- It ships operational presets - profiles, modes, personas and view presets -
  and a large derived layer: posture, pressure index, playbooks, priority
  queues, recommended actions, review SLAs. This Actor has none of that. It
  returns what GDACS published and leaves the judgement to you.
- It has a replay mode that rebuilds a previous run from a stored snapshot,
  and diffing against a named reference run. This Actor's change tracking is
  the simpler NEW / UPDATED / UNCHANGED tagging described above.
- It has named region presets. Here you pass a bounding box or a country list.
- It bundles a city table, so it can name a nearest major city for hazards
  other than earthquakes. This Actor only measures against sites you supply.

If the derived decision layer is what you are buying, buy that one. If you
want the complete event set with the source's own numbers, at a price that
lets you run it hourly, this is the one.

#### What this Actor does not do

- It does not invent severity scores, priorities or recommended actions.
- It does not merge other feeds. GDACS only. USGS, NOAA and FEMA are separate
  sources with separate quirks and belong in separate Actors.
- It cannot recover a single day where one hazard type at one alert level
  still exceeds 100 events. It reports those days instead of hiding them.
- It does not translate. GDACS publishes in English.

#### FAQ

**How far back does GDACS go?**
Events are available back to 2000. The wider the window, the more splitting
the Actor has to do, and the more queries it spends - the run report tells you
exactly how many.

**Do I need an API key, a proxy or a browser?**
No. All three GDACS endpoints used here answer plain HTTP requests with JSON.
That is checked on every live test run.

**Why did my run return nothing?**
Most often because the default level selection is Red and Orange and your
window was quiet. Widen the window, or add Green. The report's `filtered_out`
block will also tell you if your own filters removed everything.

**Can I run it on a schedule?**
That is what it is built for. Combine a short window with `onlyNew` and you
pay only for events that appeared or changed since the previous run.

**Why is `severity` sometimes tiny and sometimes in the hundreds of
thousands?**
Because the unit differs per hazard: magnitude for earthquakes, km/h for
cyclones, hectares for wildfires, square kilometres for droughts. Always read
`severity_unit` before comparing, and use `minSeverity` with a single hazard
type selected.

**What is the difference between `alert_level` and `episode_alert_level`?**
The first is the colour for the whole event, the second for the latest episode
only. They diverge when a situation is easing: the event stays Orange on its
worst moment while the current episode has already dropped to Green.

**Are empty fields a bug?**
No. `magnitude` is empty for a flood, `glide` is empty until a GLIDE number is
assigned, `event_name` is empty for everything except named storms. Turn on
`excludeEmptyFields` if you would rather not see the keys at all.

**Can I get the output straight into a map?**
Use the Map view of the dataset, or turn on `includeGeometry` for real
polygons rather than points.

#### Where does the data come from, and may I use it?

From `gdacs.org`, the Global Disaster Alert and Coordination System, a joint
framework of the United Nations and the European Commission. The Actor reads
three public endpoints: the event list, the event card and the polygon
service. It does not log in, does not bypass anything and does not touch pages
that require a browser. Check GDACS's own terms for how you may redistribute
their data; this Actor delivers it to you unchanged apart from typing and
field naming.

# Actor input Schema

## `daysBack` (type: `integer`):

How many days of history to collect, counting back from today. Ignored when you set an explicit start date below. GDACS keeps events alive for as long as they last, so a drought that started in April still shows up in a 30-day window.

## `eventTypes` (type: `array`):

Which hazards to collect. Leave empty for all six. GDACS has no separate tsunami type: tsunami information arrives inside earthquake events.

## `alertLevels` (type: `array`):

GDACS colour codes. Red is the most severe. Each level is queried separately on purpose: asking GDACS for all three at once returns a single page of green events and silently drops every red and orange one.

## `dateFrom` (type: `string`):

Earliest event date, as YYYY-MM-DD. Leave empty to use Days back instead. GDACS holds events back to 2000, and any window wider than a single page is split automatically.

## `dateTo` (type: `string`):

Latest event date, as YYYY-MM-DD. Leave empty for today. A reversed range is swapped silently rather than failing.

## `countries` (type: `array`):

Keep only events touching these countries. Accepts ISO3 codes (PHL, IDN) or full names (Philippines). Matching uses the full affected-country list, not just the country the event is centred on, and compares whole names rather than substrings.

## `bbox` (type: `array`):

Keep only events whose coordinates fall inside \[west, south, east, north] in degrees, for example \[95, -12, 142, 7] for Indonesia. A reversed box is corrected silently.

## `minAlertScore` (type: `string`):

GDACS scores every event from 0 to 3 alongside the colour. Enter a decimal such as 1.5 to keep only the harder half of the orange band. Left empty, nothing is dropped.

## `minMagnitude` (type: `string`):

Applies to earthquakes only; other hazard types pass through untouched. Enter a decimal such as 5.5.

## `minSeverity` (type: `string`):

Filters on the raw GDACS severity number. The unit differs per hazard - M for earthquakes, km/h for cyclones, hectares for wildfires, square kilometres for droughts - so use this with a single hazard type selected, otherwise it compares unlike things.

## `currentOnly` (type: `boolean`):

Keep only events GDACS still marks as current. Useful for a live situation board; leave off when building a historical archive.

## `withCoordinatesOnly` (type: `boolean`):

Drop events that carry no point geometry. Turn this on when the output feeds a map or a spatial join.

## `includeDetails` (type: `boolean`):

Adds one request per event and fills in magnitude, depth, the population GDACS estimates was exposed to strong shaking, the episode count and the map images. Turn it off for the fastest possible listing.

## `includeGeometry` (type: `boolean`):

Adds one more request per event and returns the GeoJSON polygons GDACS publishes for the affected area - cyclone tracks, flood extents, shaking contours. Off by default because it makes rows considerably larger.

## `assets` (type: `array`):

A list of objects such as \[{"name": "Manila DC", "lat": 14.6, "lon": 121.0, "radiusKm": 300}]. Every event with coordinates is measured against every site with the haversine formula, and events outside all radii keep their other fields but get no proximity data. No external geocoding is involved, so the numbers are reproducible.

## `onlyNew` (type: `boolean`):

Remembers what previous runs already delivered in a named key-value store and skips events whose alert level, episode, severity, end date and ongoing flag are all unchanged. Each row is tagged NEW, UPDATED or UNCHANGED.

## `emitUnchanged` (type: `boolean`):

Only meaningful together with the option above. Returns unchanged events too, tagged UNCHANGED, when you would rather have a full snapshot every run than pay only for changes.

## `compactOutput` (type: `boolean`):

Cuts each row down to the 15 fields needed to identify and rank an event. Handy when the output feeds an LLM context window or a spreadsheet.

## `excludeEmptyFields` (type: `boolean`):

Removes keys whose value is empty instead of returning them as null. Smaller payloads, at the cost of a ragged shape between rows.

## `webhookUrl` (type: `string`):

One message per run listing the alerts that reached the threshold below, with the GDACS report link for each. A failing webhook is recorded in the run report and never fails the run.

## `webhookMinAlertLevel` (type: `string`):

The lowest alert level worth a message. Green would notify on nearly everything, so the default is Orange.

## `compareWithSingleQuery` (type: `boolean`):

Spends one extra request to ask GDACS for the same window without splitting, and writes the number into the run report. Use it to see for yourself how much a single query leaves behind.

## `maxItems` (type: `integer`):

Hard stop on how many events end up in the dataset, which is also the hard stop on what you are charged. Zero means no limit. Left empty, a run stops at 100 so that a first look costs little.

## Actor input object example

```json
{
  "daysBack": 30,
  "eventTypes": [
    "EQ",
    "TC",
    "FL",
    "VO",
    "DR",
    "WF"
  ],
  "alertLevels": [
    "Red",
    "Orange"
  ],
  "countries": [],
  "currentOnly": false,
  "withCoordinatesOnly": false,
  "includeDetails": true,
  "includeGeometry": false,
  "onlyNew": false,
  "emitUnchanged": false,
  "compactOutput": false,
  "excludeEmptyFields": false,
  "webhookMinAlertLevel": "Orange",
  "compareWithSingleQuery": false,
  "maxItems": 100
}
```

# Actor output Schema

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

All collected rows

# 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 = {
    "daysBack": 30,
    "eventTypes": [
        "EQ",
        "TC",
        "FL",
        "VO",
        "DR",
        "WF"
    ],
    "alertLevels": [
        "Red",
        "Orange"
    ],
    "includeDetails": true,
    "maxItems": 100
};

// Run the Actor and wait for it to finish
const run = await client.actor("snow_leo_data/disaster-alerts-scraper").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 = {
    "daysBack": 30,
    "eventTypes": [
        "EQ",
        "TC",
        "FL",
        "VO",
        "DR",
        "WF",
    ],
    "alertLevels": [
        "Red",
        "Orange",
    ],
    "includeDetails": True,
    "maxItems": 100,
}

# Run the Actor and wait for it to finish
run = client.actor("snow_leo_data/disaster-alerts-scraper").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 '{
  "daysBack": 30,
  "eventTypes": [
    "EQ",
    "TC",
    "FL",
    "VO",
    "DR",
    "WF"
  ],
  "alertLevels": [
    "Red",
    "Orange"
  ],
  "includeDetails": true,
  "maxItems": 100
}' |
apify call snow_leo_data/disaster-alerts-scraper --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,snow_leo_data/disaster-alerts-scraper"
        }
    }
}
```

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/NQCjiKuDf3tCpsM2Q/builds/1k2ScQbszqdW6cq3L/openapi.json