Mercado Libre's October 16 API Change: HTTP 200 Can Still Mean No Items

October 16 changes what your application calls success

If an ERP or listing tool marks a whole creation successful solely on HTTP 200, check that logic first. The official CBT User Products size-chart guide says that from October 16, 2026, 200 confirms processing, not item creation at every destination.

The guide's October 1 update date differs from the effective rule. Its scope is the relevant cross-border listing interface and per-site results, not every API or a universal seller migration deadline.

CBT means cross-border trade. A User Product, or UP, represents a sellable attribute combination, such as one color and size. One request can address multiple destinations, so a green overall status must not conceal failed sites.

Confirm seller and product eligibility first

Read GET /users/$USER_ID and confirm user_product_seller in tags. Destinations must be available for the seller and product domain. Example site codes are demonstration targets, not a universal account-region list.

Use official category/domain discovery interfaces, then GET /catalog/charts/CBT/configurations/active_domains to confirm chart support. A domain identifies the product-specification type; changing size text cannot fix a mismatched type.

Read allowed attributes and values from the selected domain's technical_specs?section=grids, then create or obtain a compatible chart. Associate SIZE_GRID_ID, SIZE_GRID_ROW_ID, SIZE, and required size attributes in each UP's root attributes. Do not assemble combinations through variations.

After HTTP 200, inspect error on every site

POST /global/user-products/families creates a UP family, with one independent sellable combination per request-array element and corresponding response elements. POST /global/items creates one UP from an object rather than an outer array. Parse these structures separately.

For each result, inspect site_items. No site_items[].error means creation succeeded at that site; error means it did not. Partial success and even failure at all sites may still return 200.

Hypothetical example: an M-size product targets two authorized sites. A returns an item ID; B returns a chart-resolution error. Record A successful and B failed, not the entire operation complete. This is not an actual listing performed here.

An outer global 4xx with no site_items is different: failure occurred before site processing. It is not partial success, and empty results cannot establish any destination item. Correct the global request first.

Different errors require different responses

Preserve error.status, error.error, and cause fields such as code and message for each failed site. Missing charts, insufficient inputs, and domain mismatches point to different issues. Outer 200 or one short error excerpt loses important evidence.

domain_chart_mismatch indicates incompatible chart and product domain; chart_not_found means the referenced chart is absent or unavailable to the seller. Verify IDs, type, and eligibility before correction instead of automatically retrying every error.

The guide also lists temporary timeout and unavailable resolution failures, suggesting a later retry. These coexist with existing missing SIZE_GRID_ID or invalid SIZE validation errors. Use codes and their location rather than classifying all failures as network or account issues.

Retain successful items before retrying

Save successful destination item IDs after partial success, then inspect rejected sites and reasons. These IDs identify items already created. A single batch-failed flag can hide completed work during later processing.

The guide says to retain successes and consider already-created destinations before choosing retries. Distinguish success and failure explicitly instead of unconditionally resending the original batch. The current interface documentation determines available correction paths.

No dedicated retry-failed-sites-only endpoint or guarantee against duplicate creation is provided. Design subsequent actions from request records, saved IDs, and actual errors without inventing endpoints or idempotency.

An item ID still needs size-chart verification

For each successful site_items[].item_id, read GET /marketplace/items/$ITEM_ID with your authorization. Verify expected SIZE_GRID_ID, the destination-resolved SIZE_GRID_ROW_ID, and SIZE matching the UP and selected row.

Resolved row IDs can differ from the source and between destinations. Identical row IDs are not a cross-site success criterion. Check the actual size meaning at each site so the displayed size matches the intended combination.

Before October 16, verify separate handling of full success, partial success, all-site failure, and global errors, retaining per-site results. Completion depends on destination items and chart associations, not HTTP 200 or a green tool indicator alone.