Changelog and versioning

Versioning policy

The OptiWMS API is versioned in the URL (/store/v1/). Breaking changes ship under a new version path. Additive fields, new optional properties and new error details may appear on v1 without a version bump. Clients must ignore unknown JSON fields.

The OpenAPI document in the repository (docs/store-api/openapi.yaml, version in info.version) is the contract. Public pages at www.optiwms.com/developers are built from that document and these markdown pages. Every request and response example on these pages is one the OptiWMS test suite exercises.

Notification webhooks (dashboard subscriptions) use X-OptiWMS-Webhook-Version: 1 and are versioned separately from the OptiWMS API path.

1.0.0

Initial public OptiWMS API:

• Inbound: GET /ping, PUT /products, POST /products/delete, PUT /orders/{orderId}, GET /orders/{orderId}, POST /orders/{orderId}/cancel
• Outbound to the store base URL: stock, shipments, shipmentTracking, orderCancel
• HMAC signing over timestamp.method.path.body, 15-minute window, path includes percent-encoding and any base URL path prefix
• Order decision table with created, unchanged, stale, updated, canceled, and 409 codes ORDER_IN_FULFILLMENT, ORDER_SHIPPED, ORDER_CANCELED
• Release-the-pick flow and GET statuses including picking, packing, partially_shipped, shipped, pending, canceled
• Dashboard Recent activity and signature checker for remote ecommerce integrations
• Dashboard notification webhooks remain body-only X-OptiWMS-Hmac-Sha256; order topics carry a store object when the order has a channel integration

Sets (additive, still v1)

• PUT /products variant components: {sku, quantity} pairs. Omit the field to leave a stored set. [] clears a set this integration defined.
• OrderLine setId and setTitle for a set the store has already split into its products.
• Shipment lines and GET /orders/{orderId} report a set as the number of sets, not the component units.