v1.015

Adds update-behavior documentation to order and item fields that are silently ignored when syncing an existing order. No schema or endpoint changes β€” descriptions only.


πŸš€ New Endpoints

None

πŸ“– Documentation & Constraints Changes

Create or Update Order β€” order-level fields

The following fields on POST /v1/integrations/order now document their update behavior explicitly:

  • order_number (string) β€” description updated to clarify that this field cannot be changed after the order is created. Sending a different value on subsequent syncs is silently ignored.
  • customer_notes (string|null) β€” description updated to clarify that this field can only be set once. If the order already has a value for this field, any new value is ignored on update.
  • internal_notes (string|null) β€” description updated to clarify that this field can only be set once. It is always ignored when updating an existing order.
  • gift_message (string|null) β€” description updated to clarify that this field can only be set once. If the order already has a gift message, any new value is ignored on update.

Create or Update Order β€” item-level fields

The following item fields on POST /v1/integrations/order now document that they are immutable after the item is first created. Sending different values on subsequent syncs is silently ignored:

  • name (string) β€” product name cannot be changed after the item is created.
  • price (number) β€” unit price cannot be changed after the item is created.
  • image_url (string|null) β€” product image URL cannot be changed after the item is created.
  • custom_data (object) β€” custom data key-value pairs cannot be changed after the item is created.
  • b2b_attributes (array<string>) β€” B2B attributes cannot be changed after the item is created.
  • lot_requirements (object) β€” Cannot be changed when order is submitted.

Create or Update Order β€” special requirements

  • pack_list_required (boolean) β€” description updated to clarify that this field is ignored when updating an existing order. It can only be set at order creation time.

v1.014

Adds updated_at to the Order Detail Output, exposing the timestamp of the last status or data change for an order. This field is available on the single-order endpoint, the order list endpoint, and order-related webhook payloads.


πŸš€ New Endpoints

None

πŸ›  Schema & Property Updates

  • Order Detail Output β€” added updated_at (string|null, ISO 8601 datetime) indicating when the order was last updated. The field is always present in the response but may be null for historical orders that predate update tracking. Exposed across all surfaces that return this schema:
    • GET /v1/integrations/orders (single order fetch)
    • GET /v1/integrations/orders-list (order list)

v1.013

Adds support for tracking numbers on POST /v1/integrations/receiving, mirroring the existing tracking-number capability on the internal/draft receiving endpoints. Unblocks integrations (e.g. small-parcel ASNs) that need to send their carrier tracking numbers up-front.


πŸš€ New Endpoints

None

πŸ›  Schema & Property Updates

  • Create Or Update Receiving Input β€” added an optional tracking_numbers field at the top level:
    • tracking_numbers (array<string>|null) β€” list of tracking numbers for the receiving's packets. Each item is a string up to 255 characters. Accepts absent or null (no change), [] (clear all), or a populated list (replace all).

πŸ“– Documentation & Constraints Changes

  • Field semantics on POST /v1/integrations/receiving:
    • Create: the provided list is set as the receiving's tracking numbers; omitting the field results in no tracking numbers.
    • Update: omitting the field leaves existing tracking numbers untouched (preserving backwards compatibility for current integrations); an empty list clears them; a populated list replaces them. Removing a tracking number that has already been checked in is rejected with a 400 (InvalidReceivingPacketTrackingNumberException).

v1.012

Introduces an explicit Pallet β†’ Carton β†’ Item packing hierarchy on POST and GET /v1/integrations/receiving, aligned with EDI 856 (Tare β†’ Pack β†’ Item). The legacy items[].sscc field is deprecated and scheduled for removal on 2026-06-30.


πŸš€ New Endpoints

None

πŸ›  Schema & Property Updates

  • Create Or Update Receiving Input β€” added two top-level optional arrays describing the packing hierarchy:

    • cartons (array|null) β€” cartons in EDI 856 Pack level. Accepts absent, null, or []; all three normalize to an empty list.
    • pallets (array|null) β€” pallets in EDI 856 Tare level. Same null/absent/[] semantics.
  • Receiving Item Input β€” added two optional placement fields linking an item to its carton or pallet within the same payload. Exactly one is non-null when the new packing-hierarchy shape is used.

    • carton_key (string|null, max 255) β€” references cartons[].carton_key.
    • loose_units_pallet_key (string|null, max 255) β€” references pallets[].pallet_key for loose units that have no carton.
  • Receiving Output β€” added two top-level arrays surfacing the persisted packing hierarchy:

    • cartons (array of Carton Output) β€” required.
    • pallets (array of Pallet Output) β€” required.
  • Receiving Line Output β€” added two required placement fields mirroring the input:

    • carton_key (string|null)
    • loose_units_pallet_key (string|null)

πŸ“¦ New Support Schemas

  • Carton Input β€” carton_key (string, required, max 255), pallet_key (string|null, max 255, references parent pallet), identifiers (array of Receiving Packaging Identifier Input, default [], at most one per type).
  • Pallet Input β€” pallet_key (string, required, max 255), identifiers (array of Receiving Packaging Identifier Input, default [], at most one per type).
  • Receiving Packaging Identifier Input β€” type (Receiving Packaging Identifier Type, required), value (string, required, max 255). For type=SSCC, value must be a valid 18-digit GS1 SSCC.
  • Carton Output β€” carton_key (string), pallet_key (string|null), identifiers (array of Receiving Packaging Identifier Output).
  • Pallet Output β€” pallet_key (string), identifiers (array of Receiving Packaging Identifier Output).
  • Receiving Packaging Identifier Output β€” type (Receiving Packaging Identifier Type), value (string).
  • Receiving Packaging Identifier Type (enum) β€” currently a single value: SSCC. The schema is forward-compatible: future identifier types (e.g. GTIN, internal labels, carrier tracking numbers) can be added without further breaking changes.

πŸ“– Documentation & Constraints Changes

  • The cartons[] / pallets[] arrays accept three equivalent wire forms β€” absent, null, [] β€” all normalize to an empty list. Validation rules apply only when the payload uses the new shape (any item carries carton_key / loose_units_pallet_key, or cartons[] / pallets[] is non-empty).
  • When the new shape is in use, the API enforces several payload-level consistency rules (returned as 400 with field-specific paths):
    • Each item must reference exactly one of carton_key or loose_units_pallet_key (never both, never neither).
    • Every items[].carton_key must match an entry in cartons[]; every items[].loose_units_pallet_key must match an entry in pallets[]; every cartons[].pallet_key (when set) must match an entry in pallets[].
    • Every entry in cartons[] must be referenced by at least one item; every entry in pallets[] must be referenced by at least one item or carton (no orphan packing rows).
    • SSCCs are all-or-none across cartons[] βˆͺ pallets[] and must be unique within the payload.
  • A carton/pallet may carry multiple typed identifiers, but at most one identifier per type (e.g. only one SSCC).

⚠️ Deprecated

  • Receiving Item Input β€” items[].sscc is now marked deprecated and will be removed on 2026-06-30. The field is silently ignored when carton_key or loose_units_pallet_key is set on the same item. Migration: send the SSCC on the item's carton or pallet via cartons[].identifiers / pallets[].identifiers with type=SSCC instead.
  • Receiving Line Output β€” receiving_lines[].sscc description updated to reflect the same deprecation. For items placed on a carton, the field mirrors the carton's SSCC; for loose items on a pallet, it mirrors the pallet's SSCC. Consumers should migrate to reading cartons[].identifiers / pallets[].identifiers plus the new carton_key / loose_units_pallet_key placement on receiving_lines[].

v1.011

Adds parent_order_key to the shipment notification payload so integrators can identify the parent order for split orders.


πŸš€ New Endpoints

None

πŸ“– Documentation & Constraints Changes

  • Shipment Notification payload: Added parent_order_key field. For split orders it contains the order key of the parent (original) order; for all other orders it is null. The existing order_key field is unchanged.

v1.010

Documents D2C-specific pickup delay behavior in the Sandbox Complete Order endpoint.


πŸš€ New Endpoints

None

πŸ“– Documentation & Constraints Changes

  • Complete Order (POST /v1/integrations/sandbox/complete-order): Added documentation clarifying that for D2C orders, there is up to 5 minutes (but typically around 1 minute) delay between the order transitioning from awaiting_pick_up status to en_route status. During this window, a webhook is delivered to simulate the real warehouse process.

v1.009

Added shippedAtStart and shippedAtEnd filter parameters to the List Orders API endpoint.


πŸš€ New Endpoints

None

πŸ›  Schema & Property Updates

  • List Orders (GET /v1/integrations/orders-list β†’ shippedAtStart): New optional query parameter shippedAtStart (string|null, date-time format). When provided, filters results to orders shipped at or after this timestamp. Defaults to null.

  • List Orders (GET /v1/integrations/orders-list β†’ shippedAtEnd): New optional query parameter shippedAtEnd (string|null, date-time format). When provided, filters results to orders shipped before this timestamp. Defaults to null.

Added sscc (Serial Shipping Container Code) support to the receiving API β€” both as an optional input field when submitting receiving lines and as a field always present in the response.


πŸš€ New Endpoints

None

πŸ›  Schema & Property Updates

  • Receiving Line Input (POST /v1/integrations/receiving β†’ items[].sscc): New optional field sscc (string|null, exactly 18 characters) added to each line item in the receiving request body. Allows callers to associate a Serial Shipping Container Code with a specific receiving line at submission time.

  • PublicApiReceivingLineOutput (sscc): New required response field sscc (string|null) added to every receiving line in the response. Returns the SSCC associated with the line, or null if none was provided.

Enforced box packaging requirement for fragile products β€” both in code and API documentation.


πŸ“– Documentation & Constraints Changes

  • Product Push Endpoint (POST /v1/integrations/products): Added a Fragile products section to the endpoint description clarifying that when a product is marked as fragile, the required_packaging field must be set to box. This constraint is now also enforced in code. πŸ”΄ BREAKING β€” Requests creating or updating a fragile product with a required_packaging value other than box will be rejected.

Added support for the new merchant facility warehouse type in preparation for the upcoming EVCN feature.


πŸ›  Schema & Property Updates

Enums

  • WmsType: Added the value merchant_facility to the ShipMonk_WmsConnector_Order_ValueObject_WmsType enum. This new warehouse type represents merchant facility warehouses used by the upcoming EVCN feature. API consumers may encounter this value in the warehouse_wms_type field of order warehouse details but should not need to send it β€” dedicated endpoints for "pickup from merchant facility" and "package forward" fulfillment types will be introduced separately.