Changelog

Last updated October 20, 2026

Changes within v1 are additive. Anything that would remove or repurpose an existing field would ship as a new version in the path.

Date	Version	What changed
2026-08-11	v1	Initial public release. Ten endpoints: fulfilment order list and detail; order, shipment and parcel labels; order and shipment tracking submission; order and parcel tracking reads; ping. Three webhook event types: fulfilment_order.created, .cancelled and .on_hold, with HMAC-SHA256 signatures and a six-attempt retry schedule.
2026-08-25	v1	Inventory added. Three endpoints: GET /v1/warehouses, GET /v1/inventory and POST /v1/inventory, with batches of up to 200 entries applied transactionally and optional 24-hour idempotency. No change to existing endpoints, fields or webhook events.
2026-08-25	v1	POST /v1/inventory accepts absolute counts only. The adjustment field is withdrawn: an entry containing it is rejected with a validation_error, every entry must carry an integer quantity, and the Idempotency-Key header becomes optional because absolute counts are naturally safe to retry. GET /v1/inventory, GET /v1/warehouses and all other endpoints are unchanged.
2026-09-24	v1	GET /v1/shipments/{shipment_id}/tracking added: one shipment with its rollup status, order_id, sequence, carrier, parcel_count and parcels[]. Returns 404 not_found for an unknown or another seller's shipment.
2026-09-24	v1	Behaviour change: GET /v1/fulfilment-orders now rejects unknown query parameters with 400 validation_error and a hint naming the supported parameters. Before, they were silently ignored. It also now returns 400 when order_date_from is later than order_date_to, or when either is not a valid date.
2026-09-24	v1	Fulfilment orders: warehouse on an order not yet routed to a warehouse now falls back to the seller's main warehouse.
2026-09-24	v1	Parcel tracking_status values are now normalised to the documented list in Status Reference. Provider-specific values are mapped, e.g. pre_transit → pending.
2026-09-24	v1	Shipment status follows the rollup rules exactly, and a cancelled order's shipments read cancelled. A wrong HTTP method on a real path returns 405 method_not_allowed with an Allow header.
2026-09-28	v1	Fulfilment partners: seller_code on GET /v1/inventory rows and on POST /v1/inventory entries.
2026-09-29	v1	POST /v1/inventory refuses a SKU set on more than one of your products instead of picking one.
2026-09-30	v1	Orders waiting on an Omnishelf-supplied label are also hidden (404) from the shipment, parcel, label and tracking endpoints, not only the order endpoints.
2026-10-01	v1	GET /v1/ping lists four more event types: fulfilment_order.hold_released, .in_transit, .delivered and .undelivered. They are sent only with the order lifecycle switched on.
2026-10-04	v1	items[].sku is your own SKU, and product_name drops the marketplace catalogue suffix, in both API responses and webhooks. A new order's first shipment is -1; existing shipment IDs are not renumbered.
2026-10-14	v1	Docs fix: the base URL is https://api.omnishelf.com. The previously documented https://api.omnishelf.com/functions/v1/seller-api returns 404. Paths are unchanged ($BASE_URL/v1/ping). GET /v1/ping also lists fulfilment_order.status_changed, now noted in the docs.
2026-10-16	v1	Tracking submission is refused with 409 request_pending while a cancellation or SKU change request is open, and with 503 service_unavailable when it can't be checked. Nothing is sent to the fulfilment system in either case.
2026-10-19	v1	Docs fixes, no API change: every endpoint and webhook covers the orders you fulfil, after they are routed to you, not every order of your account. limit above 200 is treated as 200; only a value below 1 or not a whole number falls back to 50. The warehouse field and filter refer to routed line items. Order IDs have five digits (OMN-KONW-00042). Rate limit headers are on every authenticated response; a 401 carries none. GET /v1/ping lists the event types you can register, including the five lifecycle events, which are sent only once the order lifecycle is on.
2026-10-20	v1	Docs fixes, no API change: the rollup rules now show how the order status is worked out from its shipments. Most orders start processing; awaiting_shipment is only for retailers that buy labels on their own carrier account, and a partly delivered order reads shipped. fulfilment_order.created is sent when you can first see the order, and no event is sent when a hold is released. Parcel tracking_status can also be return_to_sender or cancelled.
2026-10-20	v1	Docs fix, no API change: every webhook you register has its own signing secret, and a delivery verifies only with the secret of the webhook it was sent for. Each event type is its own webhook. The docs previously described a single secret.