Documentation

Snowpack API

Avalanche danger by aspect and elevation, the nearest reporting instrument and how far it stands from the snow you care about, the surveyed runs, lifts, buildings and forest of 62 ski areas, and a full weather report for any place in the United States. One request, one answer, paid for by the call.

These figures are counted from the baked surveys at build time, not typed in. The lift count excludes stations, pylons, goods lines and disused lines, because none of those is a machine anybody rides.

Instruments

All 398 of them, by name, network, state, position, elevation, cadence, what each measures, and when it last reported. Search or filter, and the count follows.

A network code is the family of instrument, and it is part of the station id in every reading. Elevation is feet above sea level.

Mountains

All 62, with the survey's own counts and the instrument bound to each. The id column is what you pass to /api/resort and /api/features.

Runs counts every surveyed run line, named or not. Off by is the expected depth disagreement in inches between that instrument and the mountain's base, from the measured rule in The instrument network.

The first request

No account, no key, no signup. Ask for a place and read the answer.

# What is the weather doing at a named American place?
curl 'https://snowpack.fyi/api/weather?place=Park%20City,%20UT'

That call answers without a key and without a payment. What comes back is the free tier: the place, the conditions now, and any active alert in full. The week, the next forty-eight hours and the rest of the point are the paid answer. Ask with ?pay=x402 and the price comes back before anything is owed:

curl -i 'https://snowpack.fyi/api/weather?place=Park%20City,%20UT&pay=x402'

HTTP/2 402
content-type: application/json
{
  "accepts": [{ "scheme": "exact", "network": "eip155:8453",
                 "maxAmountRequired": "10000", "asset": "USDC" }]
}

The amount is in the token's own base units rather than dollars. USDC carries six decimals, so 10000 is one cent, which is what a weather call costs. Every endpoint in Reference carries its own price in money on its badge.

The mountain endpoints take coordinates or a resort id. Every id in Mountains works:

curl 'https://snowpack.fyi/api/resort?id=solitude'
curl 'https://snowpack.fyi/api/atlas?lat=40.6199&lon=-111.5919'

Paying per call

Payment rides on the request itself. There is nothing to sign up for and no invoice: you make the call, you are told the price, you authorize it, you make the call again with the authorization attached, and the answer comes back.

1. Request the endpoint. An unpaid request for a paid answer returns 402.
2. Read accepts from the 402 body: the chain, the asset, and the exact amount in atomic units.
3. Sign the authorization with your wallet.
4. Request again with the X-PAYMENT header. The answer returns 200, and the settlement reference comes back in X-PAYMENT-RESPONSE.

Prices are published in two places that are built from the same table, so they cannot disagree: the 402 challenge itself and the OpenAPI document, under x-payment-info on each operation.

API keys

Per-call payment suits an agent. A service making thousands of calls usually wants a key instead. A key is a signed string you send as Authorization: Bearer sp1... or ?key=, and it opens the paid tier on every endpoint without a payment step.

curl -X POST 'https://snowpack.fyi/api/x402' \
     -H 'content-type: application/json' \
     -d '{"buy":"api"}'

The key is shown once and is never stored by this service: what is kept is its public id, which names it and opens nothing. If you lose the key, issue another. Manage your keys, watch your usage and inspect your requests on the keys and usage page.

Reference

Every endpoint a buyer can call, with its parameters, what comes back, and what it does when it cannot answer. Anything not listed here is internal to the product and is not API surface.

{
  "place":   { "name": "Park City, Utah", "lat": 40.6461, "lon": -111.498 },
  "now":     { "tempF": 28, "windMph": 9, "gustMph": 17, "condition": "Light snow",
               "observedAt": "2026-01-15T19:00:00Z", "from": "measured" },
  "hours":   [ { "at": "...", "tempF": 27, "snowIn": 0.4 } ],   // 48
  "days":    [ { "date": "...", "highF": 31, "lowF": 14, "snowIn": 6, "words": "..." } ], // 10
  "alerts":  [ { "event": "Winter Storm Warning", "severity": "Severe", "text": "..." } ],
  "agree":   { "analyses": 2, "spreadF": 1.8, "spreadSnowIn": 0.9 }
}

The instrument network

Every published snow figure traces to a physical instrument standing somewhere, and the honest question is never "what is the depth" but "what is the depth where the instrument is, and how far is that from where you are asking".

The registry holds 4,395 active sites and probes 1,263 of them for the mountains in the catalogue. 394 answered on the last sweep, and 398 are bound to a mountain and listed below with what they measure and how often.

Distance from the station to the mountain

An instrument two hundred feet below the base area and half a mile down valley is not measuring the snow on the run, and pretending otherwise is the single most common way a snow figure misleads. So every binding carries three numbers and a word, and every response that quotes a station carries them too:

The rule is measured, not assumed: 0.145 inches of expected disagreement per mile of separation and 6.416 inches per thousand feet of elevation difference. missIn is what those two produce for a given binding. It is the number that stops a reading being presented as though the instrument stood on the run.

standsFor is that number in words, on the thresholds the product speaks in: under two inches of expected disagreement reads on the mountain, under six close, under twelve indicative, and past twelve weak. It pairs with standsAt, because a station stands at a distance and stands for a place. An instrument's rank is a different quantity, answered by /api/network and /api/station: its SP rank in its state by how reliably it reports. One word for both is how a caller ends up comparing two things that were never comparable, so each has its own.

How often stations report

An hourly instrument and a monthly one are both useful and they are not interchangeable. Every station in the catalogue states which it is, and a station that has fallen quiet says how many days ago it last reported rather than being dropped from the list. A binding that has been quiet past the staleness line is not used for a live figure.

Redundancy

A weather service that publishes one analysis and calls it the answer has no way to know when it is wrong. Every weather answer asks two independent paths and publishes what they said, not just the conclusion:

• agree.analyses is how many independent paths answered. Two is the target, one is reported as one.
• agree.spreadF is how far apart they were on temperature, in Fahrenheit.
• agree.spreadSnowIn is the same for new snow, in inches.

A wide spread is information in its own right: it is the honest signal that the atmosphere is doing something the models disagree about, and it is exactly when a forecast should be treated with care. The spread is published as its own figure, beside the average rather than inside it.

Where a measured reading and a modelled one both exist for the same place, they are never mixed under one label. A figure marked as measured came from an instrument and carries that instrument's name and distance; a modelled figure says so.

Terrain and lidar

Mountain geometry comes from survey. Every run, lift, building, car park, stand of forest and stretch of road in /api/features was surveyed and baked, and every one carries what the survey knew about it, with the fields the survey left empty left empty.

Two elevation resolutions

• /api/dem is the general grid, available everywhere.
• /api/hires is lidar, down to posts about three feet apart, where it has been flown. Coverage is not universal and the answer says which you got.

The distinction matters at close range. A lift tower standing in a gully, the fall of a road across a slope, and the lip of a terrain feature are all things the coarse grid smooths away and lidar keeps.

Contents of a survey

Free safety data

This is a product decision and it is not negotiable, so it is worth stating plainly on the page a developer reads before integrating.

• The avalanche danger by aspect and elevation, and the zone that issued it, answer for everyone.
• Active alerts are returned in full, not truncated to a headline.
• Ski patrol lines and the distress line are free and are never rate limited below the point of usefulness.

The trim that separates the free tier from the paid one is applied on the server, so a free caller is never handed a response with safety fields deleted and never has to ask politely for data that was already removed. What the paid tier buys is analysis, elevation band work, live instrument readings and the surveyed geometry.

Errors and limits

Rules the API follows

• A figure the API does not have is absent or null. It is never filled in with a plausible number.
• A modelled figure is never returned under a measured label.
• A station reading always carries the distance and the elevation difference between that station and the place in the request.

Avalanche danger and warnings

For a point on a mountain, /api/atlas answers with the rating of record for the avalanche zone that point sits in, the zone's own name, and where a real rose is published, the danger by aspect and by elevation band, each one as the zone issued it.

Every one of the 62 mountains is bound to its own forecast zone, office and grid point, checked when the network was last baked, so a point on the hill resolves to the right issuing office rather than to the nearest one by straight-line distance.

Ski patrol and SOS

/api/patrol answers which mountains are connected and, behind the patrol key, the open alerts on one of them. /api/sos is the other end: a hurt person raises a position, and the patrol room reads and acknowledges it.

Patrol coverage: 54 of 62 mountains

The patrol register covers 54 of the 62 mountains. The other eight have no verified line, and /api/patrol says so for them rather than returning an empty list that reads like a quiet day. A screen that promises help nobody is watching for is worse than a screen that says this mountain is not connected.

Both endpoints are free, and are never rate limited below the point of usefulness.

Peaks, roads, villages and businesses

Everything below comes back inside /api/features for one mountain. The counts are across all 62 surveys, and they are what the bake actually holds, counted.

Maps, 3D and the visor

Worth being exact about what is an endpoint and what is a thing you build with endpoints, because the difference decides what you can buy today.

Payment protocol

The short version is under Paying per call. This is the whole exchange, for an agent implementing it without a library.

curl -i 'https://snowpack.fyi/api/weather?place=Alta,%20UT&pay=x402'

HTTP/2 402
{
  "x402Version": 1,
  "accepts": [{
    "scheme":            "exact",
    "network":           "eip155:8453",
    "asset":             "USDC",
    "maxAmountRequired": "10000",     // ATOMIC units, not dollars
    "payTo":            "0x...",
    "resource":         "https://snowpack.fyi/api/weather?place=Alta,%20UT"
  }]
}

curl -i 'https://snowpack.fyi/api/weather?place=Alta,%20UT' \
     -H 'X-PAYMENT: <the signed authorization>'

HTTP/2 200
x-payment-response: <settlement reference>
{ "place": { ... }, "now": { ... }, "days": [ ... ] }

Three details to check

• Atomic against decimal. The 402 quotes atomic token units; the OpenAPI document quotes decimal USD. Reading one as the other is a factor of a million, in one direction or the other.
• The resource is the exact URL. An authorization signed for one query string does not pay for another. Quote and pay for the same request, character for character.
• A free endpoint never answers 402. If you get one from /api/conditions, /api/geocode, /api/boundaries or /api/license, that is a fault in this service and worth reporting.

Every individually priced answer is walkable: GET /api/x402?offset=&limit= pages the catalogue, ?resource=<id> fetches one, ?resort=<id> filters to a mountain.

Examples

Three whole tasks, start to finish. Each one runs as written.

A map of every mountain, coloured by new snow

One free call, no key. This is the pattern behind a regional overview: ask once, draw 62 markers, and only ask a mountain for detail when somebody presses it.

const r = await fetch('https://snowpack.fyi/api/conditions');
const { resorts } = await r.json();

// Inches of new snow decide the colour. Sort so the leader is first.
const ranked = resorts
  .filter(m => m.newIn != null)
  .sort((a, b) => b.newIn - a.newIn);

for (const m of ranked.slice(0, 5))
  console.log(`${m.name.padEnd(22)} ${String(m.newIn).padStart(4)}" new`);

Avalanche danger, without paying

The avalanche rating, its zone and any active alert are free. Note what the code does when the rose is absent: it says so, rather than assuming the danger is low.

const at = async (lat, lon) => {
  const r = await fetch(`https://snowpack.fyi/api/atlas?lat=${lat}&lon=${lon}`);
  if (!r.ok) throw new Error(`atlas answered ${r.status}`);
  return r.json();
};

const a = await at(40.6197, -111.5919);   // Solitude

console.log(a.avyZone ?? 'no zone covers this point');
console.log(a.avyLevel ? `${a.avyLevel} (${a.avyLabel})` : 'no rating of record');

// A missing rose is a real answer. Do not fill it in.
if (a.rose) for (const [aspect, band] of Object.entries(a.rose))
  console.log(` ${aspect}: ${band.join(' / ')}`);
else console.log(' this zone publishes a rating alone');

for (const alert of a.alerts ?? [])
  console.log(`ALERT ${alert.event}: ${alert.severity}`);

The runs of a mountain, cached

Geometry changes when a mountain is re-surveyed, which is months apart. Asking for it on every page load is the most common way to make an integration slow and expensive at once.

import { readFile, writeFile } from 'node:fs/promises';

async function survey(id, key){
  const cache = `./cache-${id}.json`;
  try{
    const held = JSON.parse(await readFile(cache, 'utf8'));
    // builtAt is the survey's own stamp. Re-fetch monthly, not hourly.
    if (Date.now() - new Date(held.builtAt) < 30 * 864e5) return held;
  }catch{ /* no cache yet, fall through and fetch */ }

  const r = await fetch(`https://snowpack.fyi/api/features?id=${id}`,
                       { headers: { authorization: `Bearer ${key}` } });
  if (!r.ok) throw new Error(`features answered ${r.status}`);
  const doc = await r.json();
  await writeFile(cache, JSON.stringify(doc));
  return doc;
}

const doc = await survey('alta', process.env.SNOWPACK_KEY);
const named = doc.runs.filter(r => r.name);
console.log(`${named.length} named runs, ${doc.lifts.length} lift structures`);