Partner Agnóstico: localizaciones y pedidos — Glop (Manual para partners)

Api de Glop Glop Cloud Manual para partners — Julio 2026

Partner Agnóstico: enviar tus localizaciones y tus pedidos

En pocas palabras: por cada sitio que gestionas, envías a Glop la lista de sus localizaciones (tus establecimientos, p. ej. «Cafetería María», «Bar Pepito 1») mediante dos llamadas sencillas a la API. El equipo de soporte de Glop conecta cada localización con su terminal, y a partir de ahí ya puedes enviar pedidos. Cuando tu catálogo cambie, vuelves a enviar la lista.

Lee la sección 8 antes de enviar tu primer pedido. El endpoint de pedidos responde 200 OK aunque el pedido no llegue a crearse, y acepta importes o campos mal formados sin protestar. Casi todas las incidencias de puesta en marcha salen de ahí: el formato del pedido no perdona y no avisa.

Dos conceptos clave:

Un sitio es la cuenta en la nube de Glop que soporte da de alta. Tiene una sola credencial (id + secret).
Dentro de un sitio hay una o varias localizaciones: tus establecimientos. Por ejemplo, «Bar Pepito 1» y «Bar Pepito 2» pueden ser dos localizaciones del mismo sitio.

Con la credencial de un sitio envías todas sus localizaciones de una vez.

1. Qué necesitas de soporte

Antes de empezar, el equipo de soporte de Glop da de alta tu sitio en la nube de Glop y te entrega su credencial. Por cada sitio que gestiones recibirás un único par de valores:

Dato	Para qué sirve
`id`	Identificador de la credencial de ese sitio.
`secret`	Clave secreta de ese sitio. Con `id` + `secret` obtienes el token para enviar las localizaciones del sitio.

Una credencial por sitio, no por localización: un sitio puede agrupar varias localizaciones (por ejemplo «Bar Pepito 1» y «Bar Pepito 2»), y todas se envían con la misma credencial del sitio. Solo tendrás id/secret distintos si gestionas varios sitios; en ese caso, repite esta guía con la credencial de cada sitio.

Seguridad: el secret es privado. No lo publiques en apps de cliente, webs ni repositorios. Guárdalo en tu servidor y haz las llamadas desde ahí.

2. Cómo funciona, en dos pasos

Todas las llamadas cuelgan de la dirección base https://api.glop.es/api/v1. Para cada sitio, la puesta en marcha se reduce a dos pasos:

1 Obtener un token. Con el id y el secret del sitio pides un token de acceso. Es temporal y sirve para autenticar el envío del catálogo.

2 Enviar tus localizaciones. Con ese token, mandas la lista de localizaciones del sitio a una URL fija.

Después de eso, soporte conecta cada localización con su terminal (sección 7) y ya puedes empezar a enviar pedidos (sección 8).

3. Paso 1: obtener el token

Haz una petición POST con la credencial del sitio:

POST https://api.glop.es/api/v1/auth/oauth/token Content-Type: application/json { «grant_type»: «client_credentials», «scope»: «*», «client_id»: «TU_ID», «client_secret»: «TU_SECRET» }

La respuesta incluye el token que usarás en el paso 2:

{ «token_type»: «Bearer», «expires_in»: 1296000, «access_token»: «eyJ0eXAiOiJKV1Qi…» }

Reutiliza el token: dura 15 días (expires_in, en segundos). Guárdalo y reutilizálo hasta que caduque; no pidas uno nuevo en cada envío. Cuando caduque (o recibas un 401), pide otro.

4. Paso 2: enviar tus localizaciones

Envía la lista completa de localizaciones del sitio con el token en la cabecera Authorization:

PUT https://api.glop.es/api/v1/delivery/agnostico/locations Authorization: Bearer {access_token} Content-Type: application/json { «locations»: [ { «id»: «KYTS-CAF-MARIA», «nombre»: «Cafetería María» }, { «id»: «KYTS-PEPITO-1», «nombre»: «Bar Pepito 1» }, { «id»: «KYTS-PEPITO-2», «nombre»: «Bar Pepito 2» } ] }

Ejemplo con curl:

curl -X PUT «https://api.glop.es/api/v1/delivery/agnostico/locations» \ -H «Authorization: Bearer eyJ0eXAiOiJKV1Qi…» \ -H «Content-Type: application/json» \ -d ‘{ «locations»: [ { «id»: «KYTS-CAF-MARIA», «nombre»: «Cafetería María» }, { «id»: «KYTS-PEPITO-1», «nombre»: «Bar Pepito 1» } ] }’

Glop te responde confirmando cuántas localizaciones ha guardado:

{ «status»: «ok», «count»: 2 }

Nota: puedes usar PUT o POST indistintamente sobre esta misma URL; el resultado es el mismo.

Si una sola localización va mal, no se guarda ninguna: a diferencia del envío de pedidos, este endpoint sí valida. Si a cualquier localización de la lista le falta el id, la respuesta es 422 y se rechaza el lote entero — el catálogo anterior se queda como estaba. Revisa el 422 y reenvía la lista completa corregida.

5. Contenido de cada localización

Campo	Obligatorio	Descripción
`id` (texto)	Sí	Identificador único de la localización. Debe ser estable (es lo que identifica cada localización entre un envío y el siguiente) y único a nivel global (ver el aviso de abajo). Si falta en alguna localización, se rechaza el lote entero con `422`.
`nombre` (texto)	Recomendado	Nombre del establecimiento (p. ej. «Bar Pepito 1»). Es lo que verá soporte al conectarlo con un terminal, así que ponlo claro.
`id_mesa` (texto)	No	Solo para integraciones de pedidos en mesa: mesa asociada a la localización. Si tu integración es de pedidos en mesa, acuérdalo con soporte antes de usarlo. Para delivery, omítelo.

El id debe ser único en toda la nube de Glop, no solo en tu sistema. Cuando entra un pedido, Glop busca su location entre las localizaciones de todos los clientes e integradores para saber a qué terminal enviarlo. Un identificador genérico como BARRA, 1 o MADRID puede coincidir con el de otro cliente y tu pedido acabaría en el terminal de un tercero.

Haz esto: prefija todos tus id con algo tuyo e irrepetible — KYTS-CAF-MARIA, KYTS-PEPITO-1.
No hagas esto: 1, BARRA, PEPITO-1, CENTRO.

6. Cuándo volver a enviar la lista

Repite el Paso 2 (con un token válido) cada vez que cambie el catálogo de localizaciones de un sitio: das de alta, das de baja o renombras una localización.

Envía siempre la lista completa del sitio: cada envío reemplaza por completo el catálogo anterior de ese sitio por la lista que mandas. Así altas, cambios y bajas quedan sincronizadas automáticamente: lo que dejes de incluir, se elimina. No mandes solo lo que ha cambiado.

Mantén el id estable al renombrar: cambia el nombre pero conserva el mismo id. Si cambias el id, Glop lo tratará como una localización nueva y habrá que volver a conectarla a un terminal.

Reenviar la lista no rompe las conexiones ya hechas: la conexión de cada localización con su terminal se guarda por separado y se conserva entre envíos. Mientras mantengas el mismo id de cada localización, puedes reenviar tu catálogo las veces que quieras sin perder lo que soporte ya haya configurado.

7. Qué hace soporte con lo que envías

Con la lista que has enviado, el equipo de soporte de Glop conecta cada localización con el terminal correspondiente del sitio, usando el id y el nombre que mandaste. Es un paso que hace soporte una vez; tú no tienes que intervenir.

Hasta que soporte no conecte una localización con su terminal, sus pedidos no entran. Y no recibirás ningún error al enviarlos (ver sección 8). Antes de dar por buena tu integración, confirma con soporte que el mapeo está hecho.

8. Enviar un pedido

Una vez soporte ha conectado tus localizaciones a los terminales, ya puedes enviar pedidos. Se envían a un endpoint fijo, y este envío no necesita token:

POST https://api.glop.es/api/v1/delivery/orders

8.1. Antes de nada: la respuesta no confirma nada

Este endpoint responde siempre 200 OK con un cuerpo vacío ([]), tanto si el pedido se ha creado como si se ha descartado. No hay código de error, ni mensaje, ni forma de distinguir el éxito del fallo desde la respuesta. Un 200 significa «te he oído», no «he creado el pedido».

Durante la integración, comprueba en el terminal (o con soporte) que cada pedido de prueba ha entrado de verdad. No te fíes de la respuesta.
Si un pedido no aparece, la causa casi siempre está en 8.2. Repásalas en orden.

8.2. Las cinco reglas que no perdonan

Estas son las causas reales de las incidencias que hemos visto en producción. Las dos primeras hacen que el pedido se pierda; las tres siguientes dejan que entre con datos erróneos, que suele ser peor porque nadie se da cuenta hasta que hay que cuadrar la caja.

1. Un pedido es un objeto, nunca un array — si no, se pierde. Envía { ... }, no [{ ... }]. La API espera un único pedido por llamada. Si lo envuelves en un array, no encuentra el location, descarta el pedido y te responde 200 igualmente. No se admiten lotes: un pedido, una llamada.

2. customer.email: o un email de verdad, o no lo envíes — si no, se pierde. Un valor de relleno sin @ ("-", "", "n/a") provoca un error interno y el pedido no entra.

Lo más seguro es omitir el campo: Glop genera uno solo a partir del teléfono.
Si lo envías, que sea un email real con @.
Da igual lo que mandes: Glop reescribe el email internamente para que cada pedido tenga uno distinto. No te sirve para identificar al cliente.

3. Todos los importes van en CÉNTIMOS, como número entero — si no, se cobra mal. 12,50 € se envía como 1250, no como 12.5. Afecta a payment.amount, al price de cada línea y a deliveryCost, serviceCharge, tip y discountTotal. Si envías decimales, el pedido entra igualmente y se cobra un importe incorrecto: nadie te avisa.

4. Cada línea necesita su plu — si no, entra sin artículo. El plu es el identificador del artículo en Glop. Si falta o va vacío, la línea entra en el terminal sin artículo asociado, sin ningún error.

5. _created y orderIsAlreadyPaid son fáciles de olvidar y salen caros:

Si omites _created, el pedido entra fechado el 01/01/1970.
Si omites orderIsAlreadyPaid, el pedido se marca como PAGADO. Si el cliente paga en el local, envía false explícitamente.

8.3. Ejemplo de referencia

Este es un pedido completo y correcto. Si tienes dudas, copia esta forma:

POST https://api.glop.es/api/v1/delivery/orders Content-Type: application/json { «orderId»: «NORA-1784115580339», «location»: «KYTS-CASA-NEREA-GANDIA», «_created»: «2026-07-15T11:39:40.339Z», «deliveryTime»: «2026-07-15T11:39:40.339Z», «channel»: { «slug»: «nora» }, «orderType»: 1, «orderIsAlreadyPaid»: false, «payment»: { «amount»: 1250 }, «customer»: { «name»: «David», «phoneNumber»: «624577459» }, «deliveryAddress»: [], «note»: «Pago en efectivo», «deliveryCost»: 0, «items»: [ { «plu»: «204141718», «name»: «Margarita», «price»: 1250, «quantity»: 1 } ] }

Fíjate en tres detalles del ejemplo: payment.amount y price valen 1250 (12,50 € en céntimos); no hay customer.email (se omite a propósito); y deliveryAddress es [] porque no hay reparto a domicilio.

8.4. Campos del pedido

Campo	Obligatorio	Descripción
`location` (texto)	Sí	El mismo `id` de la localización que enviaste en tu catálogo. Debe coincidir exactamente (mayúsculas y guiones incluidos). Es lo que Glop usa para saber a qué local y terminal entra el pedido.
`orderId` (texto)	Sí	Tu identificador del pedido. Si no lo envías, Glop genera uno aleatorio y pierdes la trazabilidad con tu sistema.
`_created` (fecha ISO 8601)	Sí	Fecha y hora del pedido. Si falta, el pedido entra fechado el 01/01/1970.
`payment.amount` (entero)	Sí	Importe total en céntimos. 12,50 € → `1250`.
`items` (lista)	Sí	Líneas del pedido. Ver 8.5.
`orderIsAlreadyPaid` (booleano)	Muy recomendado	`true` si ya está pagado, `false` si se paga en el local. Si lo omites, se marca como pagado.
`channel.slug` (texto)	Recomendado	Nombre de tu canal (p. ej. `nora`). Es lo que se ve como plataforma de origen en el terminal. Si falta, el pedido aparece como `deliverect`.
`customer.name` (texto)	Recomendado	Nombre del cliente. Si falta, se usa el nombre del canal.
`customer.phoneNumber` (texto)	Recomendado	Teléfono del cliente. Si falta, se registra `000000000`.
`customer.email` (texto)	No — mejor omitir	Omítelo, o envía un email real con `@`. Un valor de relleno sin `@` hace que el pedido no entre.
`id_mesa` (texto)	Solo pedidos en mesa	Si lo envías, el pedido entra como pedido en mesa en esa mesa, no como delivery. Para delivery, omítelo.
`deliveryAddress` (objeto o `[]`)	No	Dirección de entrega (`street`, `streetNumber`, `postalCode`, `city`, `notes`). Envía `[]` si no hay reparto.
`deliveryTime` (fecha ISO 8601)	No	Fecha sugerida de entrega. Si falta, se usa la hora actual.
`note` (texto)	No	Nota del pedido, llega a las observaciones del terminal. Se recorta a 150 caracteres y se le quitan los saltos de línea.
`deliveryCost`, `serviceCharge`, `tip` (enteros)	No	Gastos de envío, servicio y propina, en céntimos. Si suman más de cero, se añaden como una línea «Envío» al pedido.
`discountTotal` (entero)	No	Descuento total del pedido, en céntimos.
`orderType` (entero)	No	Tipo de pedido: `1` Pickup, `2` Delivery, `3` Eat in, `4` Curbside pickup.
`account` (texto)	No	No se usa en esta integración. Envíalo vacío (`""`) u omítelo.

8.5. Campos de cada línea (`items`)

Campo	Obligatorio	Descripción
`plu` (texto)	Sí	Identificador del artículo en Glop. Si falta o va vacío, la línea entra sin artículo.
`name` (texto)	Sí	Descripción del artículo, tal y como saldrá en el terminal.
`quantity` (entero)	Sí	Unidades. Si falta, se registra `0`.
`price` (entero)	Sí	Precio de la línea en céntimos. Si falta, se registra `0`.
`remark` (texto)	No	Nota de esa línea (p. ej. «sin cebolla»).
`discount` (entero)	No	Descuento de la línea, en céntimos.
`subItems` (lista)	No	Extras, modificadores o artículos de menú. Si vas a usarlos, acúerdalo antes con soporte: el formato del `plu` de un subitem tiene reglas propias.

8.6. Lista de comprobación antes de tu primer pedido real

1 Soporte ha conectado la localización con su terminal. Confírmalo con ellos.

2 El pedido es un objeto { ... }, no un array.

3 El location coincide carácter a carácter con un id de tu catálogo.

4 Todos los importes son enteros en céntimos. Busca cualquier decimal en tu JSON: si hay un punto, algo va mal.

5 No hay customer.email, o el que hay lleva @.

6 Están _created y orderIsAlreadyPaid, y cada línea tiene plu.

7 Has visto el pedido en el terminal. No des por bueno el 200.

9. Errores frecuentes

Síntoma	Qué comprobar
El token devuelve `401` / `invalid_client`	Revisa `id` y `secret` (que sean los del sitio correcto y sin espacios). Confirma con soporte que el sitio está dado de alta.
El envío de localizaciones devuelve `401`	El token ha caducado o falta la cabecera `Authorization: Bearer ...`. Pide un token nuevo (sección 3) y reintenta.
El envío de localizaciones devuelve `422`	El cuerpo debe ser `{ "locations": [ ... ] }` con al menos una localización, y todas con su `id`. Basta que a una le falte para que se rechace el lote entero. Envía `Content-Type: application/json`.
El pedido responde `200` y no aparece en el terminal	Es lo más habitual, y el `200` no te dice nada. Repásalo en este orden: (1) ¿va envuelto en un array `[{...}]`? (2) ¿lleva `customer.email` con un valor sin `@`? (3) ¿el `location` coincide exactamente con un `id` de tu catálogo? (4) ¿ha conectado soporte esa localización con un terminal?
El pedido entra pero con importes erróneos	Los importes van en céntimos como entero: 12,50 € es `1250`, no `12.5`. Revisa `payment.amount` y el `price` de cada línea.
La línea entra sin artículo	Falta el `plu` de esa línea, o va vacío.
El pedido aparece fechado el 01/01/1970	Falta `_created`.
El pedido aparece como pagado sin estarlo	Falta `orderIsAlreadyPaid`. Envía `false` explícitamente cuando el cliente pague en el local.
El pedido aparece como `deliverect` y no con tu nombre	Falta `channel.slug`.
El pedido entra en el terminal de otro cliente	Tu `id` de localización choca con el de otro integrador. Usa identificadores prefijados con algo tuyo (sección 5) y avisa a soporte.
Los pedidos no llegan al terminal correcto	La conexión localización→terminal la hace soporte. Avísales indicando el `id`/`nombre` de la localización afectada.

Soporte: ante cualquier duda sobre la credencial de un sitio, el envío de pedidos o la conexión de las localizaciones con los terminales, contacta con el equipo de soporte de Glop que dio de alta tus sitios. Si un pedido no entra, ten a mano el orderId, el location y el JSON exacto que enviaste: sin eso no se puede diagnosticar.

Glop — Partner Agnóstico: enviar tus localizaciones y tus pedidos — Manual para partners — Julio 2026