Mercado Libre CBT order lifecycle and shipping: from paid order to delivered parcel, by logistic type

Where the order lives

Orders belong to marketplace users, not to the global account

A Global Selling account has one global user, which owns authentication, and one marketplace user per country and logistic type combination: Mexico Remote, Mexico Fulfillment, Brazil Remote, Chile Remote, Chile Fulfillment, Colombia Remote. Listings are published and orders are received by those child users. The global user's access token reads all of them, so an integration polls /marketplace/orders/search with the global token and filters by seller.id for one child, or by site (MLM, MLB, MLC, MCO) for one country. Mercado Libre also sends notifications on the marketplace_orders topic, and its own guidance is that notifications, not polling alone, are how an integration learns about changes in time.

Two traps in the search response. First, a cart purchase comes back with a top-level id that Mercado Libre says not to use; the order ids are in the orders node, and a pack_id on the order means /marketplace/orders/pack/{pack_id} returns every order in that cart, which may share one shipment id. Second, the order carries item ids from the child marketplace (MLM..., MCO...) plus a parent_item_id with the CBT prefix; matching to your catalog by seller_sku is what keeps one SKU mapped across all countries.

Step 1

Order status: only paid means ship

One more signal arrives after payment: a fraud alert. When Mercado Libre's bank and card checks flag an order after approval, the order gets the tag fraud_risk_detected and an orders_v2 notification. The instruction is to cancel and not ship; if it already left, recovery goes through the Mercado Libre or Mercado Pago sites. Order totals on CBT are in USD; each line carries unit_price, sale_fee, and a base_exchange_rate for the local currency.

Step 2

The shipment record decides who does what

Every order carries a shipping.id. GET /marketplace/shipments/{id} (with the x-format-new header, mandatory since March 2021) returns the shipment with a logistic block: mode me1 or me2, and a type. That pair is the whole fulfillment instruction.

Shipment statuses run pending (created), handling (paid), ready_to_ship (the carrier authorization exists and the label is available), shipped, then delivered or not_delivered, with cancelled as the exit. A substatus refines each: ready_to_ship with printed once the label was fetched, handling with waiting_for_label_generation before that. The /shipments/{id}/history resource returns the full status and substatus trail with timestamps, which is what settles "when was it really handed over" in a claim.

Step 3

The handling deadline is a date on the shipment

GET /marketplace/shipments/{id}/lead_time returns the promise Mercado Libre made to the buyer. estimated_handling_limit is the date by which you must dispatch; the whole day counts, and the next day it is marked delayed, which shows up as handling_delayed in the delay list. The same object carries estimated_delivery_limit, the date after which the buyer can cancel for a refund if the parcel has not arrived, and estimated_delivery_final, the date that decides delivered versus not_delivered on a claim. The program rule Mercado Libre publishes for Remote shipments is hand-off to the carrier within 3 business days of the order; the shipment's lead_time is the per-order version of that rule and is the one to build against.

Step 4

Customs paperwork and the Colombia IMEI rule

Cross-border parcels need a declaration. Mercado Libre generates a proforma invoice per order, returned by GET /marketplace/orders/{id}/invoice, for use in the customs declaration on the parcel. Two data points feed it correctly: the dimensions and weight on each listing, which Mercado Libre uses to compute shipping and taxes per country, and the declared_value on the shipment record.

Colombia adds a rule for phones. For items in category MCO1055, an IMEI must be on the label. The API takes it as POST /marketplace/orders/{id}/attributes with name IMEI and a 15-digit value; a value of the wrong length or on an order outside that category is rejected. This is the same serial-per-unit discipline Back Market requires, and an integration that already records serials at ship can supply it without a second workflow.

Automation

How InfiPlex runs a CBT order

InfiPlex pulls Global Selling orders about every 15 minutes with the global token, imports the paid ones with their lines matched by seller SKU across every child marketplace, and routes each to a warehouse or 3PL by your rules, next to your Amazon and Shopify orders. For the partnered-carrier flow, the DHL label Mercado Libre provides prints directly from InfiPlex in the normal pick-and-pack screen, and the handling deadline is the order's ship-by date. For own-logistics shipments, the tracking you record in InfiPlex, from a label bought in InfiPlex or from a 3PL, posts to the shipment automatically. Inventory syncs per channel with a buffer sized for cross-border lead times. Set-up steps are on the Mercado Libre set-up article; the account itself starts at the Mercado Libre marketplace sign-up. If you are choosing between Global Selling and a local seller account, that comparison is on Global Selling vs a local Mercado Libre account.

Frequently asked

Questions, answered

The questions sellers ask once the first CBT orders arrive.

Resources

Related pages and references

Connecting a Global Selling account?

We have run Mercado Libre connections for years, including the parts the documentation glosses over. Tell us your current setup and we will map the connection. Contact us, email info@infiplex.com, or call 888‑770‑0857.