What shipped.

New

• New scheduled_receipts field on /v2/inventory-planning tells the plan about purchase or production orders you have already placed but not yet received — say, 200 pieces ordered three weeks ago that arrive next Tuesday. Anything arriving before a supplier could deliver a new order counts as available supply and shrinks that supplier's suggested order, instead of the endpoint recommending you buy stock that is already on a truck. Items are dated by expected arrival, as {"date": "...", "quantity": ...}.
• New committed_outflows field does the same for the outgoing side: sales orders, reservations, or anything else already booked to leave on a known date. These are firm allocations on top of the demand forecast, so 100 pieces committed to ship on the 15th reduce what's actually available — and commitments exceeding your stock increase the suggested order by exactly that backlog. Items share the shape of forecast data points (value works as an alias for quantity), so you can pass them the same way you pass history.
• When either field is present, stock_analysis returns a per-period projected_stock timeline — running stock plus arrivals minus forecast demand and committed outgoing, period by period. A negative value is your shortage warning, with the date attached. Days of coverage, the next order date, and stockout risk are all read off this projection instead of a flat daily average, so a large delivery or shipment lands on the date it actually happens rather than being smeared across the horizon.
• Each supplier recommendation reports what it netted: incoming_within_lead_time and committed_within_lead_time show exactly how much scheduled supply and committed demand landed inside that supplier's delivery window.

Requests that don't use the new fields are completely unchanged.

New

• New model=auto: per-series automatic model selection. A new identifier starts on the ensemble; as fresh actuals arrive for dates that were previously forecast, every model's prediction is scored against what actually happened. Once a single model has beaten every alternative — the ensemble included — by a clear margin across enough matured forecasts, that identifier is routed to it; while evidence is thin or the race is close, it stays on the ensemble. No configuration, no retuning: send data, and each series converges on its best model. Billed at the same 1.25× rate as the ensemble, whichever model it routes to.
• Every response to an auto request says exactly which model answered and why in model_info.auto_selection — the selected model, the reason, and the per-model accuracy scores the decision was made on. Routing is never a black box you have to trust.
• Ensemble requests now record each member model's individual forecast alongside the combined one, so per-series accuracy evidence accrues automatically from the ensemble traffic you already send — this is what powers auto. Member paths are bookkeeping only: they never appear in your dashboard, entity pages, or accuracy metrics.
• Available on /v2/forecast, /v2/batch/forecast (inline and file uploads, including per-series overrides), /v2/inventory-planning and /v2/traffic-forecasting — all four share one accuracy scorecard per identifier, so evidence gathered on one endpoint improves routing on the others. Grouped forecasts are the deliberate exception: a hierarchy is reconciled under one explicitly chosen model, so auto is rejected there rather than silently ignored.

Improved

• Batch and grouped billing now applies the documented model multiplier per series, honoring per-series model overrides. Previously every batch series billed at the standard rate regardless of the model that ran — advanced and ensemble batches were undercharged relative to the documented 1.25× rate, and that inconsistency is now closed.
• Per-series model values in batches are now validated on both the inline and file-upload paths. An unrecognized value previously forecast silently as standard; it is now rejected with a clear error naming the series.
• Updated Model Options documentation covering auto, and the inventory-planning and traffic-forecasting references now document their model choices precisely.

New

• New POST /v2/forecast/grouped endpoint forecasts a set of related series that roll up to a total, with reconciliation so the parts actually sum to the whole. Declare a hierarchy like ["region", "plan"], send one series per segment, and every level — each region, and the grand total — comes back forecast and coherent: no more presenting five segment forecasts and a total that disagrees with their sum. Submission returns immediately with an id; poll GET /v2/forecast/grouped/{id} for the result while the hierarchy processes in the background, so large hierarchies aren't limited by request timeouts.
• New structured segment field, independent of tenant_context: tenancy keeps meaning "whose data is this", segment means "which slice". Each slice — and each aggregate level — becomes its own entity with independently tracked history and forecast accuracy, so an agency can segment a client's MRR by plan without giving up the tenant key that separates their clients.
• Two reconciliation methods. bottom_up (default) forecasts the leaves and derives every aggregate as the exact sum of its children. min_trace forecasts every level independently — the smoother aggregate series included — and optimally redistributes the disagreement into a coherent set, reporting each node's unreconciled forecast alongside so you can see what coherence cost.
• Aggregate confidence ranges are built from the children's uncertainties under a stated correlation assumption between sibling errors (default 0.5, overridable per request) — not by summing the children's bounds, which assumes every segment misses low at once. The assumption in force is always echoed in the response, and when a range genuinely can't be computed the response says why instead of inventing one.

Improved

• New Grouped Forecasting documentation, and the Patterns & Segmentation guide now points at it wherever it previously advised working around incoherent roll-ups by hand.

New

• New quantiles field returns a full range of outcomes for every forecast period, not just one confidence band. Pass any of [0.1, 0.2, … 0.9] and each period comes back with a quantiles object alongside the usual lower/upper bounds. Use it to draw fan charts, or to order to a chosen service level instead of to the average. One request, one charge — previously the only way to approximate this was to call the same series repeatedly at different confidence levels, which cost more and produced near-identical lines above 0.80.
• New adjustments field applies your own assumptions on top of a forecast — "assume we lose the enterprise deal", "assume the promotion lifts Q4 by 20%". Supports multiplier and level_shift, each optionally scoped to a range of periods, applied in the order you list them. The scenario comes back as a separate adjusted block and is never stored, so exploring what-ifs can't affect the accuracy tracking on your real forecasts.
• New accumulate field sums a forecast into a single total, with optional decay for attrition and an annual discount_rate. The same request answers cumulative demand over a lead time for safety stock, customer lifetime value for a cohort, total cost of ownership, or net present value. Returns a running cumulative per period with its own confidence range, plus the assumptions used to produce it.
• New value_bounds field keeps forecasts inside the limits your data actually has: {"min": 0, "max": 100}, with either side optional. Neither the forecast nor its confidence range can land on an impossible value — no more a 140% utilisation projection or a churn rate band reaching below zero. Rates, percentages, utilisation and occupancy are forecast on a transformed scale rather than being trimmed back afterwards, so the confidence range still covers at the level it claims, and on our benchmark series it came out 14–16% better on the models that had been spending width on outcomes that could never happen.
• All four of the above work on POST /v2/batch/forecast as well, so you no longer have to choose between batching and getting a forecast that respects its own limits. Each one can be set once for the whole request and overridden on any individual series — which matters most for value_bounds, since one batch can legitimately mix a 0–100 percentage, a 0–1 rate and an unbounded revenue series. Bounds are checked against each series' own history and adjustment periods against each series' own horizon, so a scenario that runs past the end of a shorter series is rejected rather than quietly ignored. In a batch the adjusted and accumulated blocks appear inside each series' own result, not beside it.

Improved

• The confidence range on an accumulated total is now based on a correlation assumption measured against our benchmark data, rather than assuming each period's error is independent. Independence is the textbook approach and it is substantially too optimistic on real forecasts — a level error tends to persist across a horizon rather than cancelling out. The assumption in force is returned with the result, and one you supply yourself is always reported as yours.
• Asking for more detail no longer changes the forecast itself on advanced-quantized. Requesting quantiles, or lowering confidence_level below 0.80, previously fed into how the underlying model was chosen, and could move the headline number by around 10% — on one benchmark series the same request returned 1862.57 without a fan and 2057.01 with one. The model is now always fitted the same way, so what you ask to have returned can no longer change the number you get back. One-off consequence: advanced-quantized and ensemble forecasts may shift slightly against previous runs. We measured this across our benchmark suite: forecast accuracy itself is unchanged, while confidence ranges came out around 2% wider on average. We took that as a fair price for a number that no longer moves depending on what you ask for.
• New Patterns & Segmentation documentation covering how to forecast per segment or cohort with tenant_context, break a total into its components, forecast rates and percentages, and build fan charts — including where each approach has limits.
• Documented tenant_context as a general-purpose second key, not just a multi-tenancy field. It has always worked for any dimension you want to forecast along — plan, region, store, channel, cohort — but nothing said so.
• The batch endpoints now also accept confidence_level, the name the single-forecast endpoint uses, alongside the confidence they have always used — the two endpoints had different names for the same field. The lowest accepted value on batch also drops from 0.5 to 0.10, matching single forecasts. Existing requests are unaffected.

Fixed

• Corrected the date format used throughout our documentation examples. Several showed dates as "2024-01", which the API rejects — copying one of those examples produced a validation error rather than a forecast. All examples now use the YYYY-MM-DD format the API accepts.
• Removed the include_history field from the batch endpoints. It was accepted but never had any effect on the response.
• Fixed batch processing performing far more database work than necessary on larger batches, which could surface as slow processing or intermittent errors on batches with many series.
• Uploaded batch files now validate periods per series the same way an inline batch request does — it had to be between 1 and 365 there, but anything at all was accepted in an uploaded file, where an out-of-range value could stall the rest of the batch it was in.

Improved

• The default confidence_level is now 0.80, previously 0.95. This matches the range our models genuinely produce, so the returned band reflects real uncertainty rather than being stretched to a level the underlying models cannot support. Requests that pass confidence_level explicitly are unaffected.
• The ensemble model now gives more weight to the variants that forecast best on our data, instead of averaging all three equally.
• Ensemble confidence ranges are no longer widened past what the underlying models actually predict, so the reported range is one the models genuinely support.
• Confidence ranges are now steadier from one period to the next on shorter histories, where they could previously swing widely between neighbouring periods.

Fixed

• Fixed the standard model falling back to a fixed placeholder confidence range on many datasets instead of a real statistical one. The affected ranges were far narrower than the true uncertainty, which could make forecasts look more certain than they were.
• Fixed yearly seasonality being applied with a shortened, out-of-step cycle on roughly two-to-three year monthly histories, so seasonal patterns are now modelled against the correct yearly period.
• Fixed a data-sufficiency check for seasonality being calculated and then ignored, which could allow a seasonal model to be fitted on too little history.
• Expanded regression coverage around confidence ranges, seasonal periods, and model selection.

New

• New model=advanced-patched variant: a patch-based advanced model that delivers advanced-level accuracy with response times comparable to the standard model — making advanced forecasting viable for real-time use. Billed at the same rate as other advanced models.
• New model=advanced-quantized value: the new canonical name for our existing advanced model. The model=advanced value is kept for backwards-compatibility reasons and behaves identically.
• The ensemble model now combines the standard model and both advanced variants into a single forecast for even better outlier smoothing.
• New selection_metric field lets you control which back-testing error metric decides the winning model: auto (default — unchanged behavior), combined (0.6·MASE + 0.4·sMAPE, balances accuracy and trend), mase, or smape. The metric actually used is echoed at meta.selection_metric, with per-model scores under model_info.selection_scores. Applies to the standard model; the advanced variants honor mase / smape where supported.

Improved

• Ensemble requests now run all underlying models concurrently instead of sequentially, significantly reducing response times.
• Forecasts built from shorter histories now do a better job following a clear upward or downward trend, instead of sometimes settling into a flat line.
• The playground's "Why this forecast?" panel now ranks models by the exact score used to pick the winner, so the highlighted model is always the best one.

Fixed

• Fixed the playground occasionally leaving out your most recent data point and starting the forecast one period too early.

Improved

• Usage & Billing -> Estimated Cost now has a "View breakdown" button which will show how the monthly bill is calculated, including discounts and more.

Fixed

• Fixed start_date being ignored when set to a date after the dataset, causing forecasts to always begin from the last data point instead of the requested start date.
• The gap between the dataset end and the requested start_date is now zero-filled at the target frequency, so the model trains on a continuous series and naturally produces forecasts from the correct date.

Improved

• Improved data handling so time-based aggregation better preserves source activity, reducing the chance of missed demand in non-boundary timestamps.
• Improved multi-series forecast outputs so each series consistently returns the requested horizon.
• Strengthened Analyze responses with more stable result structures and clearer error details when upstream analysis is unavailable.
• Expanded regression coverage to help prevent these issues from recurring.

Fixed

• Hourly forecasting aggregation bug fixed, and results should now better detect seasonality.

Improved

• Forecast periods now align more reliably to the requested schedule across daily, monthly, and multi-series requests.
• Multi-series responses now keep each series on a consistent timeline with the expected number of returned periods.
• Traffic planning now supports longer-range quarterly and yearly capacity timing.

Fixed

• Resolved date drift in planning outputs so repeated runs no longer shift delivery, reorder, or alert dates.
• Expanded regression coverage around date alignment to reduce timeline-related regressions.

Improved

• Forecast options now behave more consistently across traffic, inventory, and standard forecasting workflows.
• Series identifiers are now handled more clearly in multi-tenant requests to reduce cross-context mix-ups.
• Forecasting services now use a more unified model layer and deployment structure for steadier API-to-model service behavior.

Fixed

• Resolved fine-tuning toggle inconsistencies so advanced-model requests apply the expected setting more reliably.
• Expanded regression coverage around multi-series horizon output and option propagation.

Improved

• Improved intelligent aggregation so hourly, daily, and weekly requests use frequency-aware windows for more reliable handling of recent and historical activity.
• Added preflight safeguards that estimate dataset expansion before resampling, helping prevent runaway workloads on very large date ranges.
• Introduced cumulative protection across multi-series processing to keep larger requests more stable under heavy load.

Fixed

• Resolved confidence-bound ordering in advanced forecast responses so interval ranges are selected more consistently.
• Expanded regression coverage around aggregation behavior and scaling guardrails to reduce repeat reliability issues.

Improved

• Improved request handling so heavy forecasting and analysis workloads stay more responsive during busy periods.
• Optimized multi-series processing to reduce repeated work, improving performance for larger batch-style requests.
• Added smarter compute allocation to better balance forecast throughput across concurrent traffic.

Fixed

• Removed unnecessary extra processing steps in forecast horizon handling to keep results consistent and reduce avoidable overhead.

New

• At an additional cost, you can now ensemble both of our models into one forecast with higher accuracy. This is slightly slower than the advanced model by itself, but should generally be favourable over either as it smoothens out any extreme outliers impressively well. Internal and beta testing yielded 17% improvement over advanced model and more than 50% improvement over standard model.
• New model=ensemble field in forecasting and batch endpoints to use ensemble model

New

• Introducing a new Advanced model, at a slightly increased cost, which improves forecasts for new identifiers and smaller datasets, as well as improves overall results by up to 30% across scores. This model is slower and is not recommended to use in live-forecasting for large datasets.
• New model=advanced field in forecasting and batch endpoints to select model

Improved

• Enhanced regularization techniques in Prophet and ARIMA models
• Improved cross-validation strategies for small datasets
• Updated documentation with best practices for avoiding overfitting

New

• Multi-layer seasonality detection for complex patterns
• Holiday and special event impact analysis
• New seasonality field in Analyze endpoint

Improved

• 40% faster Prophet model initialization
• Reduced memory usage for large datasets

New

• POST /v2/batch endpoint for up to 1,000 Series
• Parallel processing with 50% cost reduction
• Webhook support for async batch processing
• Polling endpoint for Batch processing status: GET /v2/batch/{batchToken}

Fixed

• Fixed edge case in Croston method for zero-inflated data
• Resolved timezone handling in hourly forecasts

New

• Customizable confidence levels (50%, 80%, 95%, 99%)
• Prediction intervals for each forecast point
• Uncertainty quantification metrics

Improved

• Better handling of outliers in confidence calculations
• Improved documentation with Python and PHP examples

New

• PHP SDK with Composer support
• Python SDK with type hints
• Node.js/TypeScript SDK with async/await
• Ruby gem for Rails applications

Breaking

• New RESTful API structure with versioned endpoints
• Updated authentication using Bearer tokens
• Standardized error response format

New

• 9 new forecasting algorithms with automatic selection
• Multi-region deployment for lower latency