New: minimum shelf life fields on Seller Products
General Information
-
Change Type:
No-breaking - Summary: Seller products accept two new optional fields to configure the minimum shelf life, in days, of perishable products.
Affected Endpoints
New fields
-
inbound_minimum_shelf_life(integer, days, >= 1): minimum remaining shelf life a unit must have to be received into a Melonn warehouse. -
storage_minimum_shelf_life(integer, days, >= 1): minimum remaining shelf life a unit must keep while stored to remain available for orders.
null is not accepted. On update, omitted fields keep their stored value.Validation
When both values are set,inbound_minimum_shelf_life must be greater than or equal to storage_minimum_shelf_life. On update, a field you do not send is compared using its stored value. Otherwise the request returns 400:Additional Notes
- Compatibility/Impact: ✅ 100% backward compatible. Pure addition to the request bodies: no field was removed or renamed.
Changed: List Seller Suppliers returns warehouse configurations
General Information
-
Change Type:
No-breaking - Summary: List Seller Suppliers now returns each supplier’s unpacking configuration per warehouse. This entry also corrects the documentation of the three seller supplier endpoints to match their actual behavior.
Affected Endpoints
List Seller Suppliers — warehouse_configurations
Each supplier with at least one unpacking configuration now includes warehouse_configurations, ordered by warehouse_id. Each item carries id, seller_supplier_id, warehouse_id, unpacking_type and validation_type.Suppliers without configurations are unchanged: the key is absent, not an empty array. Treat a missing key as “no configuration”. The warehouse default (DEFERRED / FREE) applies.Documentation corrections
No behavior changed in this section. The documentation now matches what the API already does.-
List Seller Suppliers: the pagination object is
meta_dataand includestotal_count. It was documented asmeta.per_pageaccepts up to 100. -
Update Seller Supplier: the path parameter accepts your own
external_idas well as the Melonnid. It is matched againstexternal_idfirst. -
Update Seller Supplier: each warehouse configuration you send is written in full. An omitted
unpacking_typeorvalidation_typeis reset to its default rather than kept. Always send both. -
Create / Update Seller Supplier: sending
warehouse_configurationswithout a negotiated agreement with Melonn returns403, not422.422is reserved for invalid configurations.
Additional Notes
- Compatibility/Impact: ✅ 100% backward compatible. Pure addition to the list response: no key was removed or renamed.
New: Create and Update Seller Supplier
Added
-
Create Seller Supplier (
POST /seller-suppliers): create suppliers from your integration, optionally with an unpacking configuration per warehouse (warehouse_configurations). -
Update Seller Supplier (
PUT /seller-suppliers/{id}): update supplier fields, warehouse configurations, or both. Send only what changes. -
external_idon suppliers: your own identifier, unique per seller. Creating a supplier with an existingexternal_idreturns409with the id of the existing supplier. -
List Seller Suppliers: new optional filter
external_id. -
Get Supplier Order: new
attachmentsarray with the order’s documents and reception photos, each with a signed download URL valid for 1 hour.
Changed
unpacking_typeandvalidation_typecan only be changed from their defaults (DEFERRED/FREE) under a negotiated agreement with Melonn. Otherwise the request returns422.
Deprecated
- Supplier fields
returns_address_l1,returns_address_l2,returns_city,returns_regionandreturns_country: no longer required, ignored if sent, and no longer returned by List Seller Suppliers.
Changed: `required[]` relaxed on Create Supplier Order, `active` added to Business
Changed: required[] relaxed on Create Supplier Order, active added to Business
General Information
-
Change Type:
No-breaking - Summary: Ten fields are no longer required when creating a supplier order, six of them are now deprecated and discarded, and each business delivery location now reports whether it is the active one.
Affected Endpoints
Create Supplier Order — fewer required fields
required[] is now just seller_supplier_id, destination_warehouse_code, external_order_number and line_items.These ten left it: tracking_number, comments, return_address_l1, return_address_l2, return_city, return_region, return_country, return_postal_code, courier_company_id, shipped_packages.Nothing to do if you already send them. All ten remain declared and accepted, so existing requests keep working byte for byte. There is no sunset date and no version in which they become an error.The six return_\* fields are deprecated: accepted and discarded rather than stored. Sending them never fails the request.shipped_packages is absent-or-non-empty — omitting it is valid, an empty array is still rejected.Supplier order responses — deprecated keys are omitted
For orders created after this change, the sixreturn_\* keys are absent from the detail and list responses — not null. Orders created before it still return their stored value.If your integration reads those fields, treat a missing key as “no return address” rather than assuming presence.Business — active per delivery location
Each entry in delivery_locations now carries active (boolean or null). A business can hold several locations while only one is active, and this field is what distinguishes them. null means it was never set.Pure addition: no existing key was removed or renamed.Additional Notes
- Compatibility/Impact: ✅ 100% backward compatible. The contract only relaxes and adds. No request that works today stops working.
- The response change is an omission of deprecated fields, so clients that already tolerate their absence need no update.
New: for Sell Order API
New: Supplier Order States
New: for Courier companies API
New: Supplier Orders API
1 - New: Supplier Orders API
General Information
Affected Endpoints
Additional Notes
Compatibility/Impact: ✅ 100% backward compatible - Does not affect existing query2 - New: Webhook Events Added
General Information
Events
- Supplier Order - Created
- Supplier Order - Cancelled
- Supplier Order - Closed
- Supplier Order Package - Unpacked
Additional Notes
Compatibility/Impact: ✅ 100% backward compatible - Does not affect existing webhook configurationsNew: Enhanced Get Return Order Details endpoint
1 - New: Enhanced Get Return Order Details endpoint
General Information
- Change Type: No-breaking
- Summary: Added new fields to line_items_summary response to include received quantity information for unpacked return orders
Affected Endpoints
-
qty_received_ok: Quantity of items received in good condition -
qty_received_ok_restocked: Quantity of items received in good condition that were restocked -
qty_received_ok_not_restocked: Quantity of items received in good condition that were not restocked -
qty_received_defective: Quantity of items received in defective condition
content array. The content field is now optional (can be undefined instead of empty array when product is not composite).Additional Notes
Compatibility/Impact: ✅ 100% backward compatible - New fields are optional and only present when return order has been unpacked,2 - New: webhook events added
General Information
- Change Type: No-breaking
-
Summary: The following events are added to the list of events for webhook configuration.
-
Buyer Return Order - Canceled -
Buyer Return Order - Unpacked
-
Additional Notes
-
Buyer Return Order - Canceled: Triggered when a return order is canceled. A return order can only be canceled if it is in “Created” or “TransportServiceRequested” state. Event:BUYER_RETURN_ORDER/CANCELED -
Buyer Return Order - Unpacked: Triggered when the return order items have been unpacked and verified at the warehouse.
New: V2 for Buyer return orders API
1 - New: V2 for Buyer return orders API
General Information
-
Change Type:
No-breaking - Summary: expose new endpoint for list and cancel buyer return orders
Affected Endpoints
Additional Notes
- Compatibility/Impact: ✅ 100% backward compatible - Does not affect existing query
2 - New: webhook events added
General Information
-
Change Type:
No-breaking - Summary: The following events are added to the list of events for webhook configuration.
- Buyer Return Order - Created
- Buyer Return Order - Received at Warehouse
- Buyer Return Order - Label Generated
New: get promise data from Sell Order API
1 - New: get promise data from Sell Order API
General Information
-
Change Type:
No-breaking -
Summary: Optional parameter
fields=sell_order_promisesis added to the GET endpoint for sell orders to provide delivery promise information
Affected Endpoints
Migration
Steps to follow:
- No migration required - The change is completely optional and backward compatible
-
To get promises: Add
?fields=sell_order_promisesto existing query
Quick Examples
Request (without promises → with promises)
Without promises:Response (new fields added)
Additional fields in current response:Additional Notes
- Compatibility/Impact: ✅ 100% backward compatible - Does not affect existing query
-
Available fields:
-
sell_order_promise_info: Information about packaging and processing promises -
sell_order_attempt: Information about shipping and delivery promises
-
- Recommended usage: Include the parameter only when promise information is needed to optimize performance
2 - New: webhook events added
General Information
-
Change Type:
No-breaking - Summary: The following events are added to the list of events for webhook configuration.
- Orden de venta - Cancelada
- Orden de venta - Entregada al comprador
- Orden de venta - Items Reservados
- Orden de venta - Recogida por el comprador
- Orden de venta - Recibida válida
- Orden de venta - En tránsito