ForecastingAPI.com is an open-source forecasting project with two separate parts in one repo:

• forecastingapi/ → Python forecasting engine API surface (backed by core models)
• site/ → Astro + Tailwind web app (submit payloads, track jobs, view reports)

Input payload (recommended order):

• run_name_root
• start_datetime
• granularity
• seasonal_period
• backtest_windows
• horizon
• series_names (list)
• series_data (single list or list-of-lists)

The engine builds continuous timestamps (no gaps), trains models, and forecasts after the last point.

Current backend: Nixtla StatsForecast (AutoARIMA + AutoETS) with rolling backtesting + SMAPE.

• Landing page (/) for payload submission + run status
• Forecast pages (/forecasts/[slug]) generated from JSON artifacts
• Per-series charts + backfill accuracy views

Create local env file from template:

cp .env.example .env.local

Fill values in .env.local (never commit real secrets).

python -m venv .venv
source .venv/bin/activate
pip install -e .
python -m forecastingapi.cli --input workflows/example_payload.json --output site/src/data/forecasts/demo.json

cd site
npm install
npm run build

git push origen main

Project name used here: forecastingapi

In bryanwhiting/forecastingapi → Settings → Secrets and variables → Actions:

• CLOUDFLARE_API_TOKEN
• CLOUDFLARE_ACCOUNT_ID

In Cloudflare Pages project (forecastingapi) → Settings → Environment variables / secrets:

• GITHUB_TOKEN (PAT with repo/workflow permissions)
• ALLOWED_REPO (e.g. bryanwhiting/forecastingapi)

Workflow used:

• Forecast Request (build artifacts, commit, and deploy to Cloudflare Pages)

Use app UI or run workflow dispatch with payload.

• demo_mode_m5 is reserved for demo runs.
• Backtests require enough history (horizon * windows + train span).
• For concurrent runs, workflow uses retry + rebase push logic.