listo es una herramienta de línea de comandos para la API de Listo Delivery.
Hace cinco cosas que de otra forma tendrías que armar tú:
- Iniciar sesión sin copiar una llave a ningún lado.
- Recibir tus webhooks en tu propia computadora, firmados como los firma producción, sin dirección pública y sin túnel.
- Mandar un evento de prueba de cualquier tipo.
- Seguir tus llamadas a la API en cuanto ocurren.
- Crear, consultar y cancelar envíos, y reproducir un escenario de repartidor en uno de prueba.
--live. El modo de prueba
usa tu credencial de prueba y no mueve dinero (ve modo de prueba).
El modo real necesita --live, y cada comando que escribe en modo real te
muestra exactamente lo que está a punto de hacer y te pregunta antes.
Instálala
Elige una. Las tres instalan el mismo programa.listo en
$HOME/.listo/bin (define LISTO_INSTALL_DIR para elegir otra carpeta), imprime
la línea que debes agregar a tu PATH si esa carpeta no está en él, y no instala
nada a menos que antes pasen dos revisiones: la firma del archivo de sumas de
verificación de la versión, hecha con la llave de firma de Listo, y la suma de
verificación de la descarga. En Windows usa npm.
Comprueba que funciona:
--help con un ejemplo. Para completar comandos y opciones en
tu shell, carga una sola vez desde el perfil de tu shell el script que imprime
listo completion para bash, zsh, fish o PowerShell:
Inicia sesión
1
Compara el código
Presiona Enter para abrir la página, o abre la dirección tú. La página muestra un
código. Revisa que sea el mismo que imprimió tu terminal antes de autorizar:
así sabes que la aprobación es para la terminal que tienes enfrente y no para la
de alguien más.
2
Elige el modo y autoriza
La página ofrece Pruebas (sin dinero real) y Real (dinero real). El modo
real está disponible cuando tu saldo real tiene dinero o ya guardaste una tarjeta,
y aprobarlo pide tu contraseña. Presiona Rechazar si la solicitud no es tuya.
3
Regresa a la terminal
La terminal termina sola. La computadora ya aparece en el panel de socios, en
Llaves de API y luego Apps conectadas, como Listo CLI en MacBook de
Ana, donde Desconectar termina su acceso de inmediato.
listo login inicia sesión en esta computadora en
modo de prueba. listo login --live pide el modo real de la misma forma y lo
agrega; las dos sesiones se guardan por separado, y --live en cualquier comando
posterior elige la real. Si la página aprueba un modo distinto del que pediste, la
terminal te lo dice.
Dónde se guarda la sesión: en el almacén de credenciales de tu sistema operativo
(el Llavero de macOS, el Administrador de credenciales de Windows o el Secret
Service en Linux). Cuando ningún almacén responde, como en un contenedor, usa un
archivo que solo tú puedes leer, y la última línea de la salida dice cuál usó.
LISTO_NO_KEYRING=1 fuerza el archivo.
listo whoami le pregunta a la API a qué empresa y en qué modo pertenece la
credencial, y listo logout termina la sesión de un modo (listo logout --live
para el modo real): la sesión se revoca en Listo y se borra de esta computadora.
Con una llave de API
¿Ya tienes una llave del panel? Guárdala, o defínela solo para una shell:LISTO_API_KEY gana sobre una sesión guardada. Una llave de prueba
(lst_test_...) funciona sin --live, y una llave real (lst_live_...) solo
con él; mezclarlas se rechaza antes de cualquier llamada, con la opción que debes
agregar o quitar.
Sin terminal
En un script, un contenedor o un trabajo de CI no hay nadie que presione Enter. Pide el código y termina el inicio de sesión desde otra shell:verification_url tú, compara el código y autoriza. Luego corre el comando
de next_step en la máquina que lo pidió, y guarda la sesión:
login sin terminal hace lo mismo que --non-interactive. El código vence, y la
terminal lo dice (“El código venció antes de que lo aprobaran”) y nombra el
comando que debes correr otra vez. --key, --non-interactive y --complete no
se pueden combinar.
Recibe tus webhooks en tu computadora
listen abre una conexión en vivo con tu cuenta y manda cada evento que Listo
emite para ella, en el modo elegido, a la dirección que diste. Una línea por
evento: la hora, el tipo, el id del evento, lo que respondió tu servidor y cuánto
tardó. Presiona Ctrl+C para detenerlo. Nada tiene que ser alcanzable desde
internet.
Verifica igual que en producción
Cada evento se manda como unPOST con el JSON del evento, byte por byte como lo
escribe el emisor de webhooks de Listo, con un encabezado X-Listo-Signature
(t=...,v1=...) y un User-Agent de listo-cli/<versión>. Así que el código que
lo verifica es el que vas a publicar: el verificador del SDK, sobre el cuerpo
crudo, con un secreto.
listen. Pásalo donde ese ejemplo lee
LISTO_WEBHOOK_SECRETS (el ejemplo recibe una lista separada por comas, así que
un solo secreto es una lista de uno). Tres cosas que debes saber de él:
- Se crea en tu computadora, para
listen. No es el secreto de tu endpoint del panel, y ese nunca sale de Listo. En desarrollo verificas con el secreto que imprimiólisten; en producción, con el de tu endpoint. Leer ambos de la misma variable de entorno en tu app es toda la diferencia. - No cambia. Se crea la primera vez y es el mismo en cada arranque, así que lo
configuras una vez.
listo listen --print-secretlo imprime y termina, que es lo que quieres en un script:export LISTO_WEBHOOK_SECRET=$(listo listen --print-secret). - Prueba y real tienen cada uno el suyo, y
listo logoutborra el secreto del modo que termina.
Qué hace listen con tu respuesta
Manda cada evento una sola vez y nunca reintenta: un 500 se muestra en rojo
para que arregles tu manejador y vuelvas a disparar el evento. Una respuesta de
redirección se reporta como la respuesta que es, no se sigue. Un servidor que no
está corriendo es una línea que dice que no se pudo conectar, y listen sigue con
el siguiente evento. Una petición que tarda más de 30 segundos se abandona.
Para recibir solo algunos tipos, nómbralos:
Cuando se cae la conexión
listen se reconecta solo y te avisa (“Se perdió la conexión, reconectando en 2
s…”). Al volver, lee los eventos escritos mientras tanto de
GET /v1/events, a partir
del último evento que vio, y manda los que no recibiste, del más antiguo al más
nuevo, cada evento una vez (“Reconectado. Eventos que se perdieron sin conexión:
3.”). El filtro --events también se aplica a ellos. Lo que no repite:
- Nada de antes de que
listenarrancara. La primera conexión no se pone al día con nada; empieza desde ahora. - Posiciones del repartidor (
delivery.courier_location). La lista de eventos las deja fuera a menos que pidas ese tipo, y una posición tan vieja no sirve. - Más de 2,000 eventos a la vez. Una caída de un día no encola un día de tráfico.
listen que está corriendo se detiene con “La sesión terminó.” y el comando para
iniciar sesión otra vez.
Manda un evento de prueba
trigger registra un evento de ejemplo de ese tipo, marcado test: true, y se lo
entrega a las sesiones de listen de tu cuenta. No llama a la URL de tu webhook,
así que no necesita que haya una configurada. Los ocho tipos son
delivery.status_changed, delivery.updated, delivery.courier_location,
withdrawal.updated, store.updated, store.connected,
delivery.message_skipped y delivery.rated.
Agrega --deliver para además enviarlo por POST a la URL de webhook que
configuraste en el panel para el modo, como sale un evento real:
GET /v1/webhook_deliveries.
Con --deliver y sin URL para el modo, la API responde
webhook_endpoint_not_configured, y
mandar más de 30 eventos de prueba por hora responde
test_webhook_limit_reached. Es la misma
llamada que POST /v1/test_webhooks.
Sigue tus llamadas a la API
/v1/ de tu cuenta, en cuanto se hace, la haga quien la
haga: la hora, el método, la ruta, el estado (verde, o rojo desde 400), cuánto
tardó, el código de error cuando falló y el id de la solicitud. Ese id es el que
debes citar a soporte, y el que buscas en
GET /v1/request_logs.
--status failed muestra solo las respuestas desde 400, succeeded las demás, y
--endpoint recibe el valor exacto que muestra una fila del registro. Las
lecturas que listo hace por su cuenta para ponerse al día después de perder la
conexión se ocultan, para que no llenen tu registro; agrega --all para verlas.
Se reconecta y se pone al día igual que listen.
Crea y consulta envíos
order.json es el cuerpo de POST /v1/deliveries
tal cual, y la API lo valida: ve Cotiza y crea un envío.
Pasa el JSON con --data @order.json, con --data @- o redirigiéndolo, o escríbelo
en la misma línea de --data. El comando genera una Idempotency-Key para la
llamada y la muestra, así que repetir la misma llamada nunca reserva un segundo
repartidor. Para mandar la tuya, usa --idempotency-key.
cancel recibe --reason (customer_canceled, store_closed, item_unavailable,
wrong_address, no_longer_needed u other, el predeterminado) y --description,
una frase de explicación. Cancelar cuando un repartidor ya estaba trabajando en la
orden se cobra como cargo por cancelación, igual que por la API.
Reproduce un escenario de repartidor
simulate crea un envío de prueba con el destino de ejemplo de la guía de inicio
y le pide al repartidor simulado que reproduzca returned, no_courier,
delayed_pickup o courier_reassigned (ve modo de prueba).
Usa tu primera tienda de prueba, o la que nombres con --store st_.... Con
listo listen corriendo en otra ventana ves los eventos que produce. Corre solo
en modo de prueba: una llave real se rechaza antes de llamar a nada.
Modo real
Agrega--live y el comando actúa sobre tu cuenta real, con dinero real y
repartidores reales. Cada línea que nombra un modo muestra la marca [LIVE] en
lugar de [TEST]. Leer no tiene ceremonia (whoami, deliveries get, listen,
logs tail). Escribir pregunta primero, y la pregunta dice exactamente qué va
a pasar:
POST /v1/quotes para la misma tienda y
el mismo destino, y con y reserva esa cotización, así que el monto que leíste
es el monto que se cobra. Cualquier respuesta que no sea y cancela, y no se
cambia nada.
deliveries cancel --livemuestra el envío, su estado y lo que puede costar la cancelación antes de preguntar.trigger --livedice que el evento se registrará en tu cuenta real, y con--deliverque llegará a la URL de tu webhook real.--yesse salta la pregunta, para scripts en los que ya decidiste confiar. En un envío igual imprime la frase, para que el registro diga qué se hizo.- Sin terminal donde preguntar (un script, una redirección) y sin
--yes, el comando se rechaza con código de salida 2 y la líneaAgrega --yes.. Nunca sigue por su cuenta.
En scripts
La salida es JSON cuando agregas--json y siempre que stdout no es una terminal,
así que una redirección siempre recibe algo que un programa puede leer; el color
aparece solo en una terminal y NO_COLOR lo apaga.
listen y logs tail imprimen un objeto JSON
por línea. Un error va a stderr como un objeto JSON (code, message, y param,
doc_url, request_id y next_step cuando los hay), y las líneas para personas
que dicen qué pasó (Listo, Se envió, la frase de confirmación) van también a
stderr, así que stdout no lleva nada más que JSON.
Idioma
La herramienta habla español o inglés. Usa el idioma que pidas con--lang es o
--lang en, si no LISTO_LANG, si no el de tu computadora (LC_ALL,
LC_MESSAGES, LANG, y en una Mac el idioma del sistema), y todo lo que empiece
con es es español. Los comandos, las opciones y las llaves del JSON se quedan en
inglés. El idioma también viaja a la API en cada llamada, así que el message de
un error llega en él.
Variables de entorno
Mantenla al día
Una vez al día, en una terminal,listo imprime una línea en stderr cuando existe
una versión más nueva, con el comando que la actualiza según cómo la instalaste.
Nunca se imprime con --json ni cuando la salida se redirige.
listo update reemplaza el programa mismo cuando lo instalaste con el script de
instalación, después de revisar la descarga contra la llave de firma de la versión
y su suma de verificación; no se reemplaza nada a menos que pasen las dos. Para una
copia de npm o de Homebrew imprime el comando de esa herramienta. listo update --check solo te dice si existe una versión más nueva. Nunca se actualiza en
segundo plano, para que la herramienta que estás usando no cambie debajo de ti a
mitad de una sesión.