Sal a producción

Salir a producción es cambiar una credencial por otra. No hay otro host, no hay cambio de versión y no hay una forma distinta de armar las peticiones: el mismo código que despachó a un repartidor simulado despacha a uno real en cuanto manda una llave real. Por eso vale la pena leer el resto de esta página. Nada te va a avisar que se te pasó algo; la primera señal va a ser un repartidor real en una dirección real.

​

Qué cambia de verdad

Todo lo demás es idéntico: los mismos endpoints, las mismas formas de los objetos, los mismos errores, los mismos eventos, el mismo esquema de firma.

​

Antes de hacer el cambio

• Lee los Términos para Partners. Se suman a los términos generales de Listo y cubren la API, tus llaves, el modo de prueba y el modo real, el nivel de acceso de cada tienda, quién paga cada envío y cómo reportas un incidente en uno. Una persona de tu equipo los acepta en el panel por todo el equipo. Mientras nadie los haya aceptado, la API y el panel siguen funcionando, pero no puedes presentar reportes de incidentes.
• Emite una llave real y guárdala como una contraseña. Las llaves se muestran una sola vez y pueden hacer todo lo que su modo permite, salvo que las emitas de solo lectura (pueden leer y nada más, así que son las que conviene darle a un agente de IA o a una herramienta de monitoreo). Mantenlas del lado del servidor y fuera de tu repositorio. Si se filtra una, revócala en el panel; la revocación surte efecto de inmediato.
• Apunta un endpoint de webhooks real a producción, con su propio secreto. Los dos modos tienen URLs de endpoint y secretos distintos. Un endpoint real sin configurar simplemente significa que los eventos no se mandan, y nada se va a quejar.
• Fondea el plan antes de crear una tienda. Cada tienda real lleva un Plan Listo que se te cobra a ti, y su primer mes se cobra en la misma petición POST /v1/stores que la crea. Fondea primero el saldo real o guarda una tarjeta en el panel, y manda un Idempotency-Key en cada creación real para que un reintento no empiece un segundo plan. Una tienda cuyo cargo falla se crea de todos modos, pero sus envíos se rechazan con 402 plan_required hasta que se pague el mes. Ve plan y cobro.
• Crea tus tiendas reales. Una tienda pertenece al mundo en el que se creó, así que tus tiendas de prueba no existen para una llave real. Dale a cada una el teléfono al que de verdad puede llamar un repartidor y sus instrucciones reales de recolección. Un restaurante que ya usa Listo con una cuenta propia se conecta en lugar de crearse: ve conecta un restaurante que ya usa Listo.
• Fondea el saldo real, y ponte un piso contra el cual alertar. Ve saldo y retiros.
• Registra la cuenta bancaria a la que van los retiros.
• Termina el alta de tarjeta si vas a cobrar con tarjeta. Lee GET /v1/stores/{id}/stripe_status para cada tienda real y confirma que dice connected. Hasta que lo diga, una creación con tarjeta se rechaza con card_not_ready. Los pedidos en efectivo y prepagados no necesitan nada de esto.
• Revisa que tus external_id y tus llaves de idempotencia sean únicos en producción. Los dos son únicos por modo, así que un valor que reusaste sin cuidado entre corridas de prueba tiene que ser genuinamente único entre tus pedidos reales.

​

Atiende las fallas que te saltaste

El modo de prueba rara vez produce las interesantes. Antes de mover pedidos reales, asegúrate de que cada una de estas haga algo sensato en tu código:

• 402 insufficient_balance: el pedido no se despachó. Hazlo visible para alguien que pueda recargar.
• 503 provider_unavailable y 409 cancel_failed: los dos traen "retryable": true, y los dos significan que nada cambió. Reintenta; no los trates como un pedido fallido.
• 409 no_couriers_available: todos los repartidores cerca del viaje están ocupados. Trae "retryable": true y no se creó nada, pero no es una caída: reintenta en unos minutos, un número limitado de veces, y después avísale a una persona.
• 429 rate_limited: espera los segundos que diga Retry-After.
• no_courier: un desenlace real, no un error. Decide si lo reintentas automáticamente o le preguntas a una persona, y lee failure_reason para elegir.
• Una creación que se va a timeout: repítela con el mismo Idempotency-Key. Una llave nueva manda un segundo repartidor.

Ramifica solo sobre error.code. error.message es prosa pensada para quien lea tus logs y su redacción no forma parte del contrato. Manda Accept-Language: es-MX y esos mensajes llegan en español, que vale la pena si van a acabar frente a personal que habla español.

​

Límites de tasa

600 peticiones por minuto por llave, y 300 por minuto de esas sobre POST /v1/quotes, que es la única llamada que le cuesta a Listo una petición hacia arriba. Al pasarte de cualquiera de los dos límites recibes 429 rate_limited con un encabezado Retry-After. Los límites son por llave, no por IP, así que varios servidores que comparten una llave comparten un presupuesto.

​

Ya que estés en producción

• Guarda el id o tu external_id de cada envío. Entre los dos, todo sobre un pedido se puede leer de vuelta.
• support_reference viene en cada envío. Cítalo cuando contactes a Listo por un pedido en particular; es el camino más rápido al viaje correcto.
• Está pendiente de los eventos store.updated. Que una tienda esté lista para cobrar con tarjeta puede cambiar sin que tú llames a nada.
• Concilia con GET /v1/ledger y no con los eventos que guardaste. Es el registro de cada movimiento de tu saldo, y ahí es donde te va a estar esperando un costo que cayó después de que el pedido terminó. Ve saldo y retiros.