Developer docs

Changelog

Changes to the SnowBee Public API and developer documentation.

  • Payment-capture integrations must now treat captures abandoned in Snowbee as unavailable: list requests omit them, and update requests return 409 CAPTURE_ABANDONED.

  • Product payloads now include only dynamic attributes applicable through the product's current template or global product attributes; previously stored values for attributes that are no longer applicable are omitted.

  • RetailStoreUpdated events are now sent when a retail store is released and when click & collect is connected to a company with existing released stores, so integrations can call GET /retail_stores and discover newly available collection stores without a periodic full refresh.

  • Demand Planning API sales-forecast and replenishment-parameter batches are now processed after upload, normally within a few minutes. Batch status progresses from PENDING to PROCESSING and then COMPLETED or FAILED with applied, skipped, and rejected item counts.
  • Added GET /demand_planning/sales_forecasts for reading the current forecast horizon per retail or ecom store and SKU. Results are paginated by store and include the forecast run's generatedAt timestamp so integrations can verify applied uploads.
  • Breaking (experimental Demand Planning API): Demand Planning response timestamps, including generatedAt and batch receipt, start, and completion times, are now ISO 8601 strings with an offset instead of epoch-second numbers. Clients parsing these fields as numbers must update.

  • Added an experimental tenant-wide Demand Planning API for uploading idempotent sales-forecast and replenishment-parameter batches and reading stores, current replenishment parameters, batch limits, and batch status. Uploaded batches are validated and stored but remain PENDING until processing goes live.
  • Public API clients are now limited to 1,800 requests per minute per client. Requests above the limit return 429 with Retry-After and rate-limit headers.
  • OAuth server metadata, OpenID configuration, and signing keys are now available from standard /.well-known endpoints for machine-readable authentication discovery.

  • In GET /orders/{orderIdOrNumber}, receipt and refund net/gross amounts now reconcile currency rounding when the final quantity of a sales order line is captured or returned. Earlier partial amounts stay unchanged; receipts across captures add up to the fully invoiced sales order amounts, and refunds across return orders add up to the original invoice amounts when the full quantity is returned. No integration changes are required.

  • Public API order line items can now include campaignCode. Send it on every line sold under a campaign. For NORMAL campaigns, netUnitPrice must equal the SKU's campaignPrice; any additional voucher or coupon share belongs in netUnitOrderDiscountAmount. If the campaign code is not released, does not cover the SKU on the order date, or the line price does not match the campaign rules, the order request is rejected with 400.
  • THREE_FOR_TWO order lines can also name campaignCode. The line should be priced at the basket's blended per-unit answer, at most the SKU's normal price; the campaign is recorded for reporting, while the line is stored in the same shape as a cash-register 3-for-2 sale.
  • Existing order integrations that omit campaignCode still work, but SnowBee no longer guesses campaign attribution from price. Lines without a campaign code may be recorded as plain sales even when the webshop intended a campaign sale.

  • The public API /healthcheck now probes database health and returns failure status when the API cannot reach its backing database, instead of always returning OK.

  • GET /campaigns now exposes campaignType on the campaign rather than on every SKU. The type applies to the whole campaign and tells integrations how to interpret each SKU's campaignPrice.