Resolve Demand Anomaly
POST/api/inventory-forecasting/anomalies/:id/resolve
Record a decision for a single demand anomaly so future forecasts treat the point correctly.
Authentication: Requires Bearer token.
How each status affects a subsequent build (only when that build sets exclude_detected_anomalies true):
- excluded: drop the day from the history before the baseline is computed. Use for a true one-off that should not count.
- smoothed: replace the day with its expected (model) value, keeping the day but removing the spike/gap. Use when the day should contribute a normal amount.
- kept_tagged: keep the day as-is, optionally attributed to a promotion via promo_window_id. Excluded and smoothed days are the ones anomaly cleansing acts on; kept_tagged days stay in the baseline. detected resets the point to unresolved.
Path parameter: id - the anomaly to resolve.
Body fields:
- status (required): excluded, smoothed, kept_tagged, or detected.
- promo_window_id (optional): link the point to a promo window when kept_tagged, associating the spike with a known promotion.
Request
Responses
- 200
- 401
- 403
- 404
- 422
- 429
OK
Response Headers
Unauthenticated — the bearer token is missing, revoked, expired, or malformed. Never retry automatically; fix the credential. See the Errors guide.
Forbidden — the token lacks a required scope, the endpoint is not available to API tokens, or the user behind the token lacks the permission. A human must adjust the token scopes or user permissions; do not retry.
Not found — no record with the given identifier (or the route does not exist). Verify the ID before retrying.
Validation failed — the body is a field → messages map (Laravel shape) or the platform envelope with a stable machine-readable code. Fix the payload and resubmit.
Rate limited — platform limit is 1,000 requests/min; individual tokens may carry lower limits. Honor the Retry-After header before retrying. See the Rate Limits guide.