Picker API Suite ## Sections • [Descripción General](https://app.theneo.io/pickerexpress/picker-api-suite/descripcion-general.md): Bienvenido a la documentación de Picker Express API. Picker te permitirá conectar tus plataformas y/o comercios a distintos proveedores de delivery de la región en la que te encuentras. La integración con Picker a través de su API te ofrece las siguientes capacidades: Administración de locales . Automatizar la creación de pedidos desde tu plataforma. Realizar consultas de tarifas. Recibir en tiempo real las actualizaciones de tu pedido . La siguiente guía te permitirá saber los primeros pasos, buenas practicas y las referencias de la API que debes de tomar en cuenta en tu desarrollo. • [Por Dónde Empezar](https://app.theneo.io/pickerexpress/picker-api-suite/por-donde-empezar.md): En esta página podrás ver cuales son los primeros pasos y que cosas se deben tener en cuenta antes de desarrollar la integración. Si tienes alguna duda acerca de algún concepto de nuestra plataforma, puedes visitar la página de Glosario donde tendrás información mas detallada. Ten en cuenta que para empezar a desarrollar tu integración con Picker, debes tener una cuenta creada con nosotros; o en su defecto, haber contactado a ventas para que les pueda facilitar una cuenta de desarrollo. Para poder comunicarte con ellos, puedes seguir los pasos en nuestra pagina oficial aquí . Una vez que tengas credenciales, ten en consideración que estas te permitirán acceder al dashboard. Estos son las url's del dashboard para producción y sandbox: Producción: https://dashboard.pickerexpress.com/ Sandbox: https://dev-dashboard.pickerexpress.com/ Para entender un poco la lógica que maneja Picker, una cuenta se la denomina Empresa . Cada empresa puede tener N locales (que pueden representar tiendas, restaurantes, puntos de despacho). Cada local obligatoriamente debe estar referenciado con una dirección y una geolocalización (se las requiere al momento de crearlas). Por ejemplo: Si tu empresa va a manejar 2 sucursales, deberás crear 2 locales . Para poder identificar tu empresa o local , nuestra API utiliza dos tipos de keys: API Key de Local : Permite hacer operaciones sobre cada local (actualizaciones) y permite realizar operaciones de pedidos (crear, consultar estado, consultar precio) Master Key de Empresa : Permite consultar y hacer operaciones sobre mi empresa (crear locales, consultar locales). Bajo este criterio, al integrarte tendrás un api key por cada local y un master key por tu empresa creado. Por ejemplo: Si tienes un empresa con 3 locales, básicamente tendrías 1 Master Key (representando tu empresa ) y 3 Api Keys (cada Api Key representando un local ). API KEY Al tener acceso al dashboard podrás obtener los api keys de cada local que vayas creando en la opción de Locales. En la esquina superior derecha de cada local, podrás visualizar el api key del local . MASTER KEY Para poder acceder al Master Key de tu tienda, debes ingresar a la opción de Configuraciones (representado por el engrane). En configuraciones, podrás encontrar el key de tu empresa . • [Autenticación](https://app.theneo.io/pickerexpress/picker-api-suite/autenticacion.md): La autenticación que maneja Picker API para cada enpoint es una autenticación de tipo Bearer; y usar como key el api key de tu local o el master key de tu empresa de acuerdo al endpoint que estes usando. Con Api Key Plain text curl --location 'https://dev-api.pickerexpress.com/api/createBooking' \ --header 'content-language: en' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer {{apiKey}}' \ Con Master Key Plain text curl --location 'https://dev-api.pickerexpress.com/api/createStore' \ --header 'content-language: en' \ --header 'Content-Type: application/json' \ --header 'Authorization: Bearer {{masterKey}}' \ • [Ciclo de Vida del Pedido](https://app.theneo.io/pickerexpress/picker-api-suite/ciclo-de-vida-del-pedido.md): Todo pedido creado en la plataforma de Picker es determinado por un estado. El estado de un pedido es una parte importante del ciclo de vida del mismo. Estos estados pueden indicar si el pedido esta terminado, cancelado o aun en proceso. Es importante que en la integración que se vaya a desarrollar se mapeen todos los estados posibles, para que el cliente tenga muy claro lo que significa cada estado. • [Qué es un Booking?](https://app.theneo.io/pickerexpress/picker-api-suite/ciclo-de-vida-del-pedido/que-es-un-booking.md): Un booking es la representación o entidad de un pedido dentro de la plataforma de Picker. Cada booking o pedido va a tener los siguientes elementos: Local : Es la representación del negocio/restaurante en Picker. Representa el punto de despacho con una dirección y una geolocalización . Cliente : Es el consumidor final del pedido . Representa un punto de entrega con una dirección y una geolocalización . Estado : Representa la fase en que esta el pedido actualmente. Conductor : Es la representación de la persona que se encargará de entregar el pedido al cliente. Contiene datos como número de teléfono para poder contactarse. Proveedor : Nombre del proveedor que atiende el pedido . Método de Pago : Indicará si este pedido requiere un pago contra entrega o no. Órdenes : Son todos los llamados que hace Picker hacia cada uno de los proveedores durante un pedido . Si un pedido al crearse no tiene respuesta de ningún proveedor o no hay proveedores que puedan atender sus pedidos, el pedido se guarda con el estado PROVIDER_NOT_FOUND Flujo de un pedido Pedido se crea en Picker vía Dashboard o API. Los datos de entrada determinarán que proveedores podrán atender el pedido . Ejemplo: Si el pedido es en efectivo , solo va a ser atendido por proveedores que pueden recibir el efectivo. Picker, de acuerdo a los parámetros del pedido y la configuración de proveedores que tiene el local , crea las ordenes en los proveedores. Los proveedores procesan el pedido y confirman si pueden atender el pedido o no. Si no pueden atender el pedido, su respectiva orden se anula. Cuando un proveedor asigna un conductor para el pedido, las órdenes en los demás proveedores automáticamente se cancelan. El proveedor que esta asignado al pedido será el encargado de operarlo con su conductor. De aquí en adelante el proveedor me indicará los estados del pedido . • [Ciclo de un Pedido Exitoso](https://app.theneo.io/pickerexpress/picker-api-suite/ciclo-de-vida-del-pedido/ciclo-de-un-pedido-exitoso.md): Es extremadamente recomendable que antes de crear un pedido , consultes el endpoint de Pre Checkout para conocer el costo del pedido; y con el puedas ofrecerle un precio al cliente acorde al costo de nuestros servicios. Al crear un pedido mediante el endpoint de Create Booking, el primer estado con el que va a nacer el pedido dependerá si manejas o no tiempo de preparación (en el API es representado por el campo cookTime ). Este cookTime puede ser configurado a nivel de local , empresa o puede ser enviado individualmente por cada pedido. A partir de esto, puede suceder lo siguiente: Si el pedido contiene cookTime , este nace con el estado ON_HOLD. Una vez cumplido el tiempo de preparación, pasa automáticamente a READY_FOR_PICKUP Si el pedido no tiene cookTime o es 0 , este nace con el estado READY_FOR_PICKUP Una vez que el pedido este en READY_FOR_PICKUP , el ciclo de vida de un pedido exitoso es muy lineal: Cuando el pedido esta en READY_FOR_PICKUP , esta buscando un conductor ideal para tu pedido. Cuando es aceptado por un conductor de alguna flota o proveedor, pasa al estado ACCEPTED . De ACCEPTED , pasa a ARRIVED_AT_PICKUP una vez que el conductor indica que ha llegado al local. De ARRIVED_AT_PICKUP pasa a WAY_TO_DELIVER si el conductor indica que ya abandono el local y va al punto de entrega. El pedido pasa a ARRIVED_AT_DELIVERY si el conductor indica que ya esta donde el cliente y esta presto a terminar el pedido. El pedido termina con el estado COMPLETED cuando el conductor entrega satisfactoriamente el pedido. Todas las actualizaciones de estado van a llegar por medio del webhook de UPDATE_BOOKING_STATUS . Únicamente el estado de ACCEPTED llega por medio del webhook de DRIVER_ASSIGNED ya que trae consigo los datos del conductor. • [Ciclos de Pedido No Exitoso](https://app.theneo.io/pickerexpress/picker-api-suite/ciclo-de-vida-del-pedido/ciclos-de-pedido-no-exitoso.md): Un pedido en proceso puede sufrir cancelaciones o retornos de todo tipo. Desde escenarios en que el local no requiere ya un motorizado, o cancelaciones desde el proveedor. Los escenarios de cancelación son los siguientes: Cancelado por Negocio En este escenario, un pedido es creado exitosamente. Pero durante el transcurso del pedido el negocio desea cancelarlo (puede ser vía API o via Dashboard). Cuando esto sucede, el pedido se guarda bajo el estado de CANCELLED_BY_BUSINESS . Esta cancelación puede efectuarse mientras el pedido este en: ON_HOLD READY_FOR_PICKUP ACCEPTED ARRIVED_AT_PICKUP En los 2 últimos estados (ACCEPTED y ARRIVED_AT_PICKUP), esta cancelación incurre en un costo del 50% del delivery. Cancelado por Admin En este escenario, durante el ciclo de un pedido si este esta en un estado superior a ARRIVED_AT_PICKUP, el local no podrá cancelar el pedido . Para poder cancelarlo, el usuario deberá consultar a soporte para proceder con la cancelación. En este flujo, el estado con el que se guarda el pedido es CANCELLED_BY_ADMIN . Cancelado por Proveedor Existen ocasiones en que el proveedor, ya teniendo el pedido en curso, no puede despachar o terminar el pedido . En estos escenarios, el proveedor cancela el pedido y se guarda con el estado CANCELLED_BY_DELIVERY_PROVIDER. Provider Not Found Este estado se dispara al momento en que se crea un pedido , pero ningún proveedor esta disponible para poder atender tu pedido. Para entender como se registra este estado, seguimos el siguiente flujo: Se crea un pedido en la plataforma de Picker (via API o Dashboard). Picker intenta solicitar a los proveedores activos del local si pueden efectuar la orden. Si al menos un proveedor accede a atender la orden, se efectúa la búsqueda . Si ningún proveedor puede atender el pedido, se da por finalizado el pedido y se lo guarda con el estado PROVIDER_NOT_FOUND. La disponibilidad de un proveedor va a depender distintos criterios: El método de pago del pedido (algunos proveedores no manejan el pago contra entrega o efectivo). La ubicación de entrega esta fuera de la cobertura de los proveedores. Proveedores no pueden atender el pedido por alta demanda en sus respectivas plataformas. Tienes que tomar en cuenta que la búsqueda de un conductor únicamente se la realizará con los proveedores que tengas activado en tu negocio. Si tienes desactivado un proveedor para tu negocio, la plataforma no usara a tal proveedor para las búsquedas. No Entrega (Not Delivered) Este escenario sucede cuando el conductor esta intentando entregar al pedido al cliente, pero por alguna razón no puede completar el pedido. Esto puede suceder por distintas razones: Conductor no encuentra con la dirección de entrega (Dirección errónea o incompleta) Cliente no recibe pedido o lo rechaza. Conductor no puede contactar con cliente para coordinar la entrega (Número de teléfono o datos de contacto erróneos). Hay que tener en consideración que cuando se dispara este escenario, el pedido pasará al estado NOT_DELIVERED si este no es requerido de retorno al local. Retornado Si el pedido no pudo ser entregado al cliente (bajo los escenario descritos en No Entrega), y este requiere que sea retornado al local o comercio, para al estado RETURNING , el cual indica que el pedido va de regreso al local. Una vez que el pedido sea retornado satisfactoriamente al local, pasa al estado final RETURNED. • [Estados del Pedido](https://app.theneo.io/pickerexpress/picker-api-suite/ciclo-de-vida-del-pedido/estados-del-pedido.md): A continuación presentamos un glosario de todos los estados que se tienen en Picker. Estado Descripción ON_HOLD Es el estado inicial del pedido si existe un tiempo de preparación. Durante este estado, el pedido aún no busca conductor. Pasa automáticamente a READY_FOR_PICKUP si: Se cumple el tiempo de preparación o cooktime. Se activa manualmente la búsqueda desde dashboard. Se activa mediante el endpoint de Start Search . READY_FOR_PICKUP En este estado se inicia la búsqueda de motorizados en los distintos proveedores activados para el local. Este estado se puede disparar en los siguientes escenarios. Se termina tiempo de preparación de pedido en ON_HOLD Se inicia una búsqueda manualmente Si un pedido ya con conductor ejecuta una nueva búsqueda de conductores. (Por ejemplo: Pedido en ACCEPTED con conductor vuelve a READY_FOR_PICKUP ). Si el pedido se crea sin tiempo de preparación, será el estado inicial del pedido. ACCEPTED Este estado se guarda en el pedido al momento que un proveedor asigna un motorizado al pedido. Este estado únicamente llega por medio del webhook de DRIVER_ASSIGNED ARRIVED_AT_PICKUP Cuando el conductor notifica que el conductor llego al local y esta esperando que local le entregue el pedido WAY_TO_DELIVER Cuando el conductor indica que abandono el local y va en dirección al punto de entrega ARRIVED_AT_DELIVERY Cuando el conductor llega donde el cliente y esta por terminar el pedido COMPLETED Pedido fue completado satisfactoriamente PROVIDER_NOT_FOUND Cuando ningún proveedor activado para tu local no puede atender tu pedido. No se ejecuta ninguna búsqueda CANCELLED_BY_BUSINESS Negocio dispara la cancelación del pedido. Esto puede suceder cuando: Pedido es cancelado desde dashboard Pedido es cancelado vía API por medio del endpoint de Cancel Booking CANCELLED_BY_ADMIN Cuando la cancelación es disparada por el área de Soporte de Picker CANCELLED_BY_DELIVERY_PROVIDER Cuando la cancelación es disparada por el proveedor de delivery NOT_DELIVERED Cuando el pedido no pudo ser entregado al cliente; y el paquete de entrega no puede ser devuelto al negocio RETURNING Cuando el pedido no pudo ser entregado al cliente y el pedido esta en camino a ser retornado al negocio RETURNED Cuando el pedido fue retornado exitosamente al negocio Todos los estados, a excepción del estado inicial y del ACCEPTED (que llega en webhook de DRIVER_ASSIGN ), llegan en el webhook de UPDATE_BOOKING_STATUS . • [API Reference](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference.md): En este apartado podrás encontrar todos los endpoints expuestos en nuestra API Suite. Este apartado estará dividido en cada una de las entidades a las que tendrás acceso en este API: Stores Webhooks Bookings Ten muy en cuenta las URLs que estés usando para tus endpoint. En la parte derecha de esta página, tendrás el direccionamiento a cada uno de los ambientes que tenemos. • [Stores](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/stores.md): En este apartado podrás encontrar los endpoints usados para la administración de los locales de tu empresa . Podrás encontrar los endpoints de: Create Store Get Store Get Stores Ten en consideración que los endpoints de Create Store y Get Stores usan como autenticación Master Key (para identificar el Empresa ). En cambio el de Update Store y Get Store usa Api Key (para identificar el local). • [Create Store](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/stores/create-store.md): Este endpoint te ayudará a crear una tienda en tu empresa. La función principal de este endpoint es establecer un nuevo local en la plataforma de Picker relacionado a tu empresa. Recopila varios detalles sobre la tienda en cuestión, incluida su ubicación física, información de contacto e identificación de la empresa. En concreto, recibe datos como la dirección completa de la tienda, coordenadas de geolocalización (longitud y latitud), nombre de la empresa y una referencia de dirección. El response de este endpoint es el Api Key de la tienda. • [Get Store](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/stores/get-store.md): El endpoint de Get Store servirá para consultar todos los detalles de un local identificado por su api key. Podrás consultar todos los datos ingresados al local sin importar si se lo creo vía API o vía Dashboard. • [Get Stores](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/stores/get-stores.md): El endpoint de Get Stores te permitirá consultar todos los locales que tiene el empresa. Como este endpoint se basa en el alcance que tiene el empresa, se deberá enviar en el header como autorización el Master Key del empresa. • [Webhooks](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/webhooks.md): En este apartado encontraras los endpoints a utilizar para el manejo de webhooks. Podrás encontrar los endpoints de: Get Webhooks Add Webhooks Así mismo, podrás encontrar los detalles de los payloads que se envian a los webhooks registrados según cada evento. Los eventos que se devuelven en los webhooks son: Driver Assigned Update Booking Status Para todos los endpoints de webhooks, necesitas como autorización el api key del local Si necesitas mas información acerca de los estados que llegan en los webhooks, puedes visitar la pagina de Estados del Pedido . • [Get Webhooks](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/webhooks/get-webhooks.md): El endpoint de Get Webhooks te permitirá consultar los webhooks configurados en el local. Te retornará todas las urls configuradas a los respectivos eventos del booking. Como esta configuración es por local, deberás utilizar Api Key. • [Add Webhook](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/webhooks/add-webhook.md): El endpoint de Add Webhook te permitirá agregar webhooks a los eventos que afectan un booking. Los eventos que pueden registrarse con una url para su respuesta son: DRIVER_ASSIGNED : Cuando un conductor es asignado a un pedido. UPDATE_BOOKING_STATUS : Cuando un pedido cambia de estado. Cuando cualquiera de estos eventos se dispara en nuestra plataforma, automáticamente enviamos un POST a la url registrada para el evento con el payload respectivo (Los payloads enviados por evento, los puedes revisar en páginas posteriores). Ten en cuenta que los webhooks son configurados por local. • [Driver Assigned](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/webhooks/driver-assigned.md): El evento de DRIVER_ASSIGNED se enviará al webhook registrado en el local cada vez que se asigne un nuevo conductor a un pedido. Este evento puede enviarse desde 1 hasta varias veces durante un pedido. Esto puede pasar en los siguientes escenarios: Se asigna un conductor al pedido. Se reasigna un nuevo conductor a un pedido que ya tenía un conductor. Se hace una nueva búsqueda a un pedido que ya tiene conductor asignado. Previo a esto, se elimina al conductor del pedido y este último se devuelve al estado READY_FOR_PICKUP. Cabe recalcar que si a un pedido se le asigna un conductor, automáticamente se lo pasará al estado ACCEPTED. Es recomendable de que si se va hacer tracking del pedido, debes tener guardado el id del booking para poder hacerle match al momento de que llegue el webhook en tu integración. Si el llamado al webhook registrado falla, se harán hasta 2 intentos nuevos de llamada con un intervalo de 30 segundos. • [Update Booking Status](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/webhooks/update-booking-status.md): El evento de UPDATE_BOOKING_STATUS se enviará a los webhooks registrados cada vez que un pedido cambie de estado. Por cada cambio de estado que sufra un pedido, se ejecutará un POST hacia el webhook registrado para este evento en el local. Cuando existe una cancelación de un pedido, el payload puede incluir la razón por la cual se canceló el pedido. Es recomendable de que si se va hacer tracking del pedido, debes tener guardado el id del booking para poder hacerle match al momento de que llegue el webhook en tu integración. Si tu Workspace o Empresa tiene activado la funcionalidad de Prueba de Entrega, a partir del estado WAY_TO_DELIVER, se te enviará el campo validationCode . El contenido de este campo deberá ser proveído al cliente para poder completar la entrega (el conductor solicitará este código). Si el llamado al webhook registrado falla, se harán hasta 2 intentos nuevos de llamada con un intervalo de 30 segundos. • [Pre-Booking](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/pre-booking.md): Un Pre-booking es denominada a una plantilla con datos preliminares de un pedido sin los datos del punto final de entrega. Para poder convertirlo en un booking, es necesario que se pueda ingresar la dirección de entrega mediante una url que es retornado al momento de crear o consultar un pre-booking. Una vez ingresada la dirección final, el booking se crea y se inicia automáticamente la búsqueda de un conductor. En este apartado podrás encontrar todos los endpoints utilizados para poder crear un pre-booking: Create Pre-Booking Get Pre-Booking Cancel Pre-Booking • [Create Pre-Booking](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/pre-booking/create-pre-booking.md): Esta funcionalidad esta en certificación y unicamente existe en al ambiente de sandbox. El endpoint de Create PreBooking te permite crear una plantilla con datos preliminares de un pedido, a excepción de la ubicación de entrega. Para poder ingresar la ubicación de entrega, la respuesta de este endpoint te retornará una url (que deberás proveerla al cliente final) donde se podrá ingresar la ubicación del cliente final. Una vez ingresado la ubicación final en el link indicado, el pedido comenzará su proceso de búsqueda de repartidores. Ten en consideración que mientras que la dirección final no haya sido ingresada mediante el link, el pedido no estará creado ni se visualizará en tu tablero de pedidos de tu Dashboard. • [Get Pre-Booking](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/pre-booking/get-pre-booking.md): Esta funcionalidad esta en certificación y unicamente existe en al ambiente de sandbox. Con el endpoint de Get Pre-Booking podrás obtener los detalles de un pre-booking de acuerdo a su id. Ojo. El prebooking que consultes deberá haber sido procesado y creado con el Api Key del local que estes usando. Si intentas buscar un id de un prebooking que pertenece a otro local, la plataforma no te lo devolverá. • [Cancel Pre-Booking](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/pre-booking/cancel-pre-booking.md): Esta funcionalidad esta en certificación y unicamente existe en al ambiente de sandbox. El endpoint de Cancel Pre-Booking te permitirá cancelar un pre-booking antes de que se haya ingrese la dirección final (y que por ende se haya convertido en un booking). Podrás cancelar cualquier pedido perteneciente al negocio identificado por el Api Key. Así como el endpoint de Get Pre-Booking, solo vas a poder cancelar pedidos pertenecientes al negocio referenciado por el Api Key • [Bookings](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/bookings.md): En este apartado encontrarás todos los endpoints relacionados a los pedidos o bookings. Podras encontrar desde consultas de precios, creación de bookings, consultas y cancelaciones. Los endpoints que puedes encontrar en esta sección son: Pre Checkout Create Booking Get Booking Details Get Cancel Reasons Cancel Booking Start Search Todos estos endpoints usan como autorización el api key del negocio. • [Pre Checkout](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/bookings/pre-checkout.md): El endpoint de Pre Checkout te permitirá consultar precios y valores del pedido que necesites realizar. Además de eso, te indicará si es posible que podamos atender tu pedido (si el pedido cubre una distancia muy larga entre el local y el punto de entrega; o el punto de entrega esta fuera de cobertura, devolveremos un mensaje de error). Para este endpoint es obligatorio la locación del punto de entrega. La ubicación del local ya la obtenemos automáticamente por el Api Key del negocio que usas en la autorización. Otros datos que puedes ingresar en este endpoint son: paymentMethod : Es el método de pago que usarás para el pedido. En el caso que exista un pago en efectivo al momento de entregar el pedido, deberás usar CASH. Caso contrario, si no hay ningún pago de por medio y el conductor unicamente tiene que recoger el pedido y entregarle al cliente, deberás usar CARD. carName: Indicá el tipo de vehículo que necesitas para tu pedido. Si es un pedido de dimensiones pequeñas y necesitas una moto, debes ingresar aquí BIKE . Si tu pedido es de mayores dimensiones y necesitas un coche, deberás usar LITE . • [Create Booking](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/bookings/create-booking.md): El endpoint de Create Booking es el mas importante de todo el Api Suite de Picker. Este endpoint es el que permitirá poder crear un pedido dentro de la plataforma de Picker. La ejecución de este endpoint desencadenará todo el proceso del pedido (desde su creación, búsqueda de proveedores, actualizaciones de estado y finalización). Si necesitas mas detalles, puede visitar la sección de Ciclo de Vida del Pedido . Cada dato que se ingrese aquí es muy importante para el correcto desarrollo del pedido: Los datos del cliente como sus nombres deben ser claros y completos. Así mismo como su número de teléfono y dirección. Recuerda que en cuanto mas exacto sea el pedido, menos inconvenientes tendrá el conductor para localizar y entregarle su pedido al cliente. El método de pago con el cual se procesará el pedido. Así podemos procesar tu pedido con los proveedores que apliquen para el método de pago indicado. Los valores del pedido como orderAmount y businessDeliveryFee. Estos valores son importantes para que el proveedor tenga claro el costo del pedido, en el caso que exista alguna novedad (no importa si el pedido es en efectivo o no). El parámetro sendTrackingLink te indicará si necesitas que nosotros como Picker enviemos el link de tracking al cliente. El envío de tracking dependerá de las configuraciones que tienes en tu local (Whatsapp o Correo). Cooktime que representa el tiempo de preparación del pedido. Este tiempo correrá apenas se cree el pedido. Una vez cumplido el tiempo, se iniciará la búsqueda de un conducto. Si necesitas que la búsqueda se inicie enseguida, deberás ingresar 0. Para saber la tarifa del pedido, deberás sumar los campos priceBreakUp.baseFare + priceBreakUp.perKmCharge Es recomendable que una vez que se cree el booking, guardes el id o bookingNumericId del pedido para poder posteriormente consultarlo y hacer match en el caso que tengas activados los webhooks. • [Get Booking Details](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/bookings/get-booking-details.md): Con el endpoint de Get Booking Details podrás consultar el detalle de un booking en específico. La consulta la puedes hacer mediante cualquiera de estos 3 parámetros: bookingID: Deberás enviar el bookingNumericID obtenido en la creación del booking. id: Deberás enviar el id obtenido en la creación del booking. externalID: Deberás enviar lo que enviaste en externalBookingID al momento de crear el pedido. Puedes usar cualquiera de los 3 métodos para consultar el pedido. Ojo. El booking que consultes deberá haber sido procesado y creado con el Api Key del local que estes usando. Si intentas buscar un id de pedido que pertenece a otro local, la plataforma no te lo devolverá. • [Get Cancel Reasons](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/bookings/get-cancel-reasons.md): Con el endpoint de Get Cancel Reasons podrás consultar las razones de cancelación que tenemos disponibles y que puedes enviar en el caso que requieras cancelar el pedido. Ten en cuenta que utilizar estas razones no son obligatorias; sin embargo es recomendable que se la utilice para poder tener mas datos acerca de los pedidos • [Cancel Booking](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/bookings/cancel-booking.md): El endpoint de Cancel Booking te permitirá cancelar un pedido en curso. Podrás cancelar cualquier pedido perteneciente al negocio identificado por el Api Key. Puedes agregarle una razón de cancelación que puedes tomar desde el endpoint de Get Cancel Reasons . Así como el endpoint de Get Booking Details, solo vas a poder cancelar pedidos pertenecientes al negocio referenciado por el Api Key Solo podrás cancelar pedidos que estén en los siguientes estados: ON_HOLD READY_FOR_PICKUP ACCEPTED ARRIVED_AT_PICKUP • [Start Search](https://app.theneo.io/pickerexpress/picker-api-suite/api-reference/bookings/start-search.md): El endpoint de Start Search al ejecutarlo iniciará la búsqueda de conductores para pedidos que tienen cooktime. Unicamente será posible iniciar una búsqueda siempre y cuando el pedido este con el status ON_HOLD. Si el pedido ya inicio una búsqueda, se retornará como código de error 409. • [Certificación](https://app.theneo.io/pickerexpress/picker-api-suite/certificacion.md): Previo a la salida a producción, es imperativo que se coordine una reunión para poder certificar tu integración con Picker. Dentro de esta certificación se van a revisar los siguientes puntos, dependiendo de las funcionalidades que tengas integradas: Bookings: Pre Checkout Create Booking Datos correctos y concretos del cliente Dirección y Geolocalización correcta Número de teléfono válido Referencia a dirección de entrega Valores a cobrar Uso correcto de métodos de pago Uso de cook time (Opcional) Cancel Booking (Opcional) Webhooks Registro de Webhooks Interpretación de estados en su sistema Stores Create Store Get Store (Opcional) Pre Booking Create Pre Booking Datos del cliente y del negocio sea correcto Flujo de envió de link para confirmar dirección Cancel Pre Booking (Opcional) Interacción con Usuario Final Visualización de Estados Visualización de datos de pedido Visualización de Tracking de Picker Para acordar una reunión de certificación, se la puede agendar mediante este link. • [FAQ](https://app.theneo.io/pickerexpress/picker-api-suite/faq.md): ¿Es necesario usar el endpoint de pre-checkout para usar el API? No es imperativo usar el endpoint de pre-checkout; sin embargo lo recomendamos para que puedas saber con anterioridad el precio de un pedido antes de crearlo. ¿Para que me sirve el Dashboard? El Dashboard de Picker es una herramienta visual donde podrás: Visualizar, administrar y crear pedidos. Visualizar y administrar tus locales. Manejar tus configuraciones generales. Consultar los keys para la integración. ¿En que escenario debo enviar CASH o CARD en paymentMethod al crear un booking? CASH : Cuando el pedido requiere un pago contra entrega en efectivo. CARD : Cuando unicamente requieres que el conductor recoja el pedido y lo entregue en sitio. Esto funciona si de tu lado de la integración ya estas realizando el cobro al cliente (Por transferencia, pasarela de pagos, etc). ¿Qué valor debo ingresar en el campo orderAmount? Nosotros recomendamos fuertemente que se coloque el valor en bruto del pedido (sin delivery fee, descuentos u otros rubros), inclusive si el pedido tiene como método de pago CASH. Esto es necesario para la auditoría de los proveedores en el caso que suceda alguna incidencia con el pedido en curso. Acabo de crear mi pedido, pero no esta buscando en ningún proveedor. ¿Qué me esta haciendo falta? Es muy probable que tu pedido tenga cooktime y este en estado ON_HOLD. Cuando un pedido se inicia con cooktime, tiene un tiempo de espera hasta antes de iniciar una búsqueda en los proveedores. Para iniciar una búsqueda, hay las siguientes opciones: Esperar que se cumpla el tiempo de espera Iniciar la búsqueda manualmente mediante la opción de Iniciar Búsqueda en el menu del pedido en Dashboard Usar endpoint de Start Search. Me aparece que mi workspace esta suspendido. ¿Qué debo hacer? Si tu empresa esta suspendida, puedes contactar a soporte mediante la opción de chat que existe en Dashboard para conocer mas del asunto. El precio que me muestra el endpoint de Pre Checkout es distinto al que me estan cobrando. ¿Por qué sucede esto? El precio que se muestra en el Pre Checkout es solo un precio referencial aproximado al valor real que puede tener un pedido. Ten en consideración que el precio puede variar de acuerdo a varios factores, algunos de estos pueden efectuarse o no durante un pedido: Proveedor que operó el pedido Tiempos de espera Liberaciones y Reasignaciones • [Glosario](https://app.theneo.io/pickerexpress/picker-api-suite/glosario.md): Empresa: Espacio de trabajo que representa la empresa o marca, el cual puede tener 1 o mas locales asociados. Tiene un master key único, el cual es utilizado para las operaciones vía API. También es conocido como Workspace en algunas nomenclaturas. Local: Es la representación de un comercio/local/restaurante/punto de despacho en la plataforma de Picker. Cada local tiene un identificativo único (Api Key); y tiene asociado una dirección y una geolocalización necesarias para la operación. Master Key: Es el identificador único de cada empresa. Es obligatorio usarlo en cada operación vía API que requiere la identificación del empresa. Ejemplo: En el endpoint Create Store, es necesario para poder indicar a que empresa se debe asociar la tienda recién creada. Api Key: Es el identificador único de cada tienda. Es obligatorio usarlo en las operaciones vía API en que se requiere la identificación del local. Ejemplo: En el endpoint Create Booking, es necesario para poder identificar la tienda a donde el conductor tiene que recoger el pedido. Booking: Es la representación del pedido como tal en la plataforma de Picker. Cada booking o pedido tiene un identificador único interno (id), público (bookingNumericId) y un estado (statusText). Este ultimo campo representa en que estado del proceso se encuentra el pedido. Orden: Es la representación de cada llamado a un proveedor. Cuando un booking se crea, este llama a todos los proveedores que tiene activado el local; cada uno de estos llamados es una orden. Un booking puede tener de N ordenes de acuerdo al número de proveedores que puede atenderlo. Dashboard: Es la plataforma visual de Picker. Desde esta web se podrán administrar y configurar la empresa como sus locales. Para acceder al dashboard de producción haz click aquí . Restart Search: Se lo conoce también como una rebúsqueda. Sucede cuando un pedido ya con conductor ejecuta una nueva busqueda de conductor en cada proveedor debido a que el conductor asignado no puede cumplir con el pedido antes de llegar al local. Restart Search se puede disparar en estos escenarios: Proveedor cancela pedido antes de llegar al local Proveedor desasigna un conductor antes de llegar al local Soporte lo ejecuta manualmente en el caso que exista alguna novedad con el conductor del pedido