Web Parity Migration Guide

The web implementation should not invent a second backend contract layer. The rewrite already moved most important state and product rules to backend-owned APIs, and the web companion should consume those same seams directly.

Core Rules

treat the backend as the source of truth for forecast, route, trip, commerce, and settings state
prefer the canonical api/user/* namespace instead of any older me-style surface
use the backend response contracts directly instead of rebuilding or reshaping them client-side
keep business rules server-owned, especially for route safety, terrain analysis, readiness, membership, and trip accountability

Recommended Web API Entry Points

Shell And Session

GET /api/bootstrap/config
GET /api/auth/sign-in
POST /api/auth/sign-in
POST /api/auth/sign-out
GET /api/user
GET /api/user/settings
PUT /api/user/settings

Home, Forecast, And Search

GET /api/summaries/home
GET /api/forecast
GET /api/forecast/brief
GET /api/forecast/briefs
GET /api/search

Routes And Plans

GET /api/routes
POST /api/routes
GET /api/route-plans
POST /api/route-plans
GET /api/routes/:routeID/terrain-analysis
GET /api/routes/:routeID/exposure
GET /api/route-plans/:planID/safety-summary
GET /api/route-plans/:planID/readiness

Trips And Accountability

POST /api/trips/start
POST /api/trips/:id/check-in
POST /api/trips/:id/heartbeat
POST /api/decision-logs
POST /api/trips/:id/observations
GET /api/trips/:id/debrief
POST /api/trips/:id/debrief

Specific Migration Recommendations

Forecast

do not recreate rose, slope guidance, or override logic in web code
consume the effective danger metadata and slope guidance supplied by the backend

Route Intelligence

do not compute route safety on the client if the backend already has a route or geometry seam for it
use the backend terrain-analysis and exposure APIs for both user routes and shared/popular-route parity

Settings And Preferences

keep user settings round-tripped through api/user/settings
local persistence is fine for temporary UI state, but not as the canonical settings store

Search

use the unified GET /api/search surface instead of separate route, plan, forecast, and incident lookups

Analytics

send events to POST /api/analytics/events
do not couple the web client directly to the analytics sink vendor

Browser Integration Guidance

use same-origin or trusted-subdomain fetch with credentials: include
avoid custom token storage if the cookie session already covers the surface
centralize API fetch helpers around the canonical route set exposed in these docs

Documentation Workflow

When a new backend route is added:

add it to the docs registry
attach a real schema if one already exists
add defaults or prerequisites for try-it
add parity notes if the web app should consume it

That keeps the docs, OpenAPI output, and browser explorer aligned.

Use the same contracts on web, iOS, staging, and production.

Auth for Try-It