Flujos de integración
Flujo 1: creación única del servicio y seguimiento mediante webhooks
Este flujo se utiliza cuando el ERP envía el servicio una sola vez, después de finalizar el documento o albarán, y no necesita actualizar su información antes del despacho.
A partir de la creación, la planificación y la ejecución se gestionan desde Logístiko. El ERP recibe las novedades mediante webhooks enviados por Logístiko.
Cuándo utilizar este flujo
Este modelo es adecuado cuando:
- El documento se encuentra completo en el momento de crear el servicio.
- El ERP no necesita modificar el servicio después de la planificación.
- La asignación y optimización se realizan en Logístiko.
- El cliente puede exponer un endpoint para recibir webhooks.
- El ERP necesita conocer en tiempo real los cambios de estado de la ruta y los servicios.
Descripción del flujo
1. Creación del servicio
Cuando el documento o albarán está finalizado, el ERP crea el servicio mediante:
En esta llamada deben incluirse todos los datos necesarios para la planificación y ejecución:
- Referencias del servicio.
- Cliente y dirección.
- Fecha deseada.
- Horarios.
- Cantidad, peso y volumen.
- Artículos o bultos, cuando correspondan.
- Instrucciones de entrega.
- Datos de cobro, cuando correspondan.
Después de esta llamada, el ERP no necesita actualizar el servicio.
2. Asignación y optimización
Logístiko se encarga de:
- Agrupar los servicios.
- Asignarlos a una ruta.
- Asignarlos a un conductor.
- Ordenar las paradas.
- Optimizar el recorrido.
En esta fase el ERP no necesita intervenir.
3. Despacho de la ruta
Cuando la planificación está preparada, un usuario despacha la ruta desde el panel de Logístiko.
Como resultado:
- La ruta queda disponible en la aplicación del conductor.
- Logístiko envía al ERP el webhook de servicio asignado a ruta.
Documentación:
Webhook de servicio asignado a ruta
Este webhook permite al ERP conocer, entre otros datos disponibles, la ruta, el conductor y la posición asignada al servicio.
4. Inicio de la ruta
Antes de iniciar el recorrido, el conductor puede completar el formulario de inicio de ruta configurado en Logístiko.
Cuando se completa el formulario, Logístiko puede enviar:
Webhook del formulario de inicio de ruta
Posteriormente, cuando el conductor inicia la ruta desde la aplicación, Logístiko envía:
El formulario de inicio y el inicio efectivo de la ruta son eventos diferentes y pueden recibirse en comunicaciones separadas.
5. Ejecución de los servicios
Cuando el conductor llega al destino y registra la llegada en la aplicación, Logístiko envía:
Después de la llegada, el servicio puede finalizar con distintos resultados.
Servicio completado
Cuando el conductor completa correctamente el servicio, Logístiko envía:
Webhook de servicio completado
El resultado puede incluir información como:
- Fecha de finalización.
- Coordenadas.
- Observaciones.
- Firma.
- Fotografías.
- Artículos o bultos.
- Respuestas de formularios.
- Resultado final del servicio.
Servicio con incidencia
Cuando el conductor registra una incidencia, Logístiko envía:
Webhook de servicio con incidencia
La comunicación puede incluir:
- Código de incidencia.
- Descripción de la incidencia.
- Observaciones.
- Fecha y coordenadas.
- Evidencias adjuntas, cuando correspondan.
Estado forzado
En determinadas situaciones excepcionales, un usuario puede forzar el estado de un servicio.
Cuando esto ocurre, Logístiko puede enviar:
Este evento no forma parte del recorrido normal del conductor y debe tratarse como una modificación excepcional.
6. Fin de la ruta
Al terminar el recorrido, el conductor puede completar el formulario de fin de ruta.
Logístiko envía entonces:
Webhook del formulario de fin de ruta
Este evento puede incluir:
- Identificador y referencia de la ruta.
- Conductor.
- Vehículo.
- Fecha y coordenadas de finalización.
- Respuestas del formulario.
flowchart TB
%% =========================
%% 1. CREACIÓN
%% =========================
subgraph P1["1. Creación única del servicio"]
direction LR
E1["ERP<br/>Documento finalizado"]
L1["Logístiko<br/>Crea el servicio"]
E1 -->|"POST Crear servicios"| L1
end
%% =========================
%% 2. PLANIFICACIÓN
%% =========================
subgraph P2["2. Asignación y optimización"]
direction RL
E2["ERP<br/>Sin intervención"]
subgraph O2[" "]
direction TB
L2["Logístiko<br/>Asigna, agrupa y optimiza<br/>los servicios"]
end
O2 ~~~ E2
end
%% =========================
%% 3. DESPACHO
%% =========================
subgraph P3["3. Despacho de la ruta"]
direction RL
E3["ERP<br/>Recibe los servicios<br/>asignados a la ruta"]
subgraph O3[" "]
direction TB
L3A["Logístiko<br/>Despacha la ruta<br/>desde el panel"]
A3["APP conductor<br/>Recibe la ruta"]
L3B["Logístiko<br/>Envía el webhook de<br/>servicio asignado a ruta"]
L3A -->|"Ruta despachada"| A3
L3A --> L3B
end
O3 -->|"POST Webhook de despacho"| E3
end
%% =========================
%% 4. INICIO DE RUTA
%% =========================
subgraph P4["4. Inicio de ruta"]
direction RL
E4["ERP<br/>Recibe los eventos<br/>de inicio de ruta"]
subgraph O4[" "]
direction TB
A4F["APP conductor<br/>Completa el formulario<br/>de inicio de ruta"]
L4F["Logístiko<br/>Envía el webhook del<br/>formulario de inicio"]
A4S["APP conductor<br/>Inicia la ruta"]
L4S["Logístiko<br/>Envía el webhook<br/>de ruta iniciada"]
A4F --> L4F
L4F --> A4S
A4S --> L4S
end
O4 -->|"POST Webhooks de inicio"| E4
end
%% =========================
%% 5. OPERATIVA DEL SERVICIO
%% =========================
subgraph P5["5. Operativa por servicio"]
direction RL
E5["ERP<br/>Recibe los eventos<br/>del servicio"]
subgraph O5[" "]
direction TB
A5A["APP conductor<br/>Registra la llegada<br/>al destino"]
L5A["Logístiko<br/>Envía el webhook<br/>de llegada al destino"]
D5{"Resultado<br/>del servicio"}
A5E["APP conductor<br/>Completa la entrega"]
L5E["Logístiko<br/>Envía el webhook<br/>de servicio completado"]
A5I["APP conductor<br/>Registra una incidencia"]
L5I["Logístiko<br/>Envía el webhook<br/>de incidencia"]
X5["Acción excepcional<br/>Se fuerza el estado<br/>del servicio"]
L5F["Logístiko<br/>Envía el webhook<br/>de estado forzado"]
A5A --> L5A
L5A --> D5
D5 -->|"Entregado"| A5E
A5E --> L5E
D5 -->|"Incidencia"| A5I
A5I --> L5I
D5 -.->|"Opcional"| X5
X5 --> L5F
end
O5 -->|"POST Webhooks de servicio"| E5
end
%% =========================
%% 6. FIN DE RUTA
%% =========================
subgraph P6["6. Fin de ruta"]
direction RL
E6["ERP<br/>Recibe el formulario<br/>de fin de ruta"]
subgraph O6[" "]
direction TB
A6["APP conductor<br/>Completa el formulario<br/>de fin de ruta"]
L6["Logístiko<br/>Envía el webhook del<br/>formulario de fin de ruta"]
A6 --> L6
end
O6 -->|"POST Webhook de fin de ruta"| E6
end
%% Orden vertical
P1 ~~~ P2
P2 ~~~ P3
P3 ~~~ P4
P4 ~~~ P5
P5 ~~~ P6
%% Colores
classDef erp fill:#15803d,stroke:#86efac,stroke-width:2px,color:#ffffff
classDef logistiko fill:#075985,stroke:#7dd3fc,stroke-width:2px,color:#ffffff
classDef app fill:#6d28d9,stroke:#c4b5fd,stroke-width:2px,color:#ffffff
classDef inactive fill:#374151,stroke:#6b7280,stroke-width:1px,color:#d1d5db
classDef decision fill:#4c1d95,stroke:#c4b5fd,stroke-width:2px,color:#ffffff
classDef optional fill:#78350f,stroke:#fbbf24,stroke-width:2px,color:#ffffff
class E1,E3,E4,E5,E6 erp
class E2 inactive
class L1,L2,L3A,L3B,L4F,L4S,L5A,L5E,L5I,L5F,L6 logistiko
class A3,A4F,A4S,A5A,A5E,A5I,A6 app
class D5 decision
class X5 optional
%% Contenedores
style P1 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P2 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P3 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P4 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P5 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P6 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style O2 fill:transparent,stroke:transparent,color:transparent
style O3 fill:transparent,stroke:transparent,color:transparent
style O3 fill:transparent,stroke:transparent,color:transparent
style O4 fill:transparent,stroke:transparent,color:transparent
style O5 fill:transparent,stroke:transparent,color:transparent
style O6 fill:transparent,stroke:transparent,color:transparent
linkStyle default stroke:#94a3b8,stroke-width:2px
%% Documentación
click L1 "https://logistiko.readme.io/reference/servicios-crear" "Ver Crear servicios"
click L3B "https://logistiko.readme.io/reference/webhookserviceassignedtoroute" "Ver webhook de servicio asignado a ruta"
click L4F "https://logistiko.readme.io/reference/webhookroutestartform" "Ver webhook del formulario de inicio"
click L4S "https://logistiko.readme.io/reference/webhookroutestarted" "Ver webhook de ruta iniciada"
click L5A "https://logistiko.readme.io/reference/webhookservicearrived" "Ver webhook de llegada al destino"
click L5E "https://logistiko.readme.io/reference/webhookservicecompleted" "Ver webhook de servicio completado"
click L5I "https://logistiko.readme.io/reference/webhookserviceincidence" "Ver webhook de incidencia"
click L5F "https://logistiko.readme.io/reference/webhookserviceforcedstatus" "Ver webhook de estado forzado"
click L6 "https://logistiko.readme.io/reference/webhookrouteendform" "Ver webhook del formulario de fin de ruta"
Flujo 2: creación única del servicio y consulta periódica del estado
Este flujo se utiliza cuando el ERP envía el servicio una sola vez, después de finalizar el documento o albarán, pero no puede recibir webhooks por limitaciones técnicas.
La planificación y la ejecución se gestionan en Logístiko. Para conocer las novedades, el ERP consulta periódicamente el estado de cada servicio.
Cuándo utilizar este flujo
Este modelo es adecuado cuando:
- El documento se encuentra completo en el momento de crear el servicio.
- El ERP no necesita actualizar el servicio después de la planificación.
- La asignación y optimización se realizan en Logístiko.
- El sistema del cliente no puede exponer un endpoint público para webhooks.
- El ERP puede realizar consultas periódicas a la API de Logístiko.
Se recomienda utilizar webhooks siempre que sea posible. La consulta periódica genera más llamadas y puede introducir retrasos entre el cambio de estado y su recepción en el ERP.
Descripción del flujo
1. Creación del servicio
Cuando el documento o albarán está finalizado, el ERP crea el servicio mediante:
En esta llamada deben incluirse todos los datos necesarios para la planificación y ejecución:
- Referencias del servicio.
- Cliente y dirección.
- Fecha deseada.
- Horarios.
- Cantidad, peso y volumen.
- Artículos o bultos, cuando correspondan.
- Instrucciones de entrega.
- Datos de cobro, cuando correspondan.
Después de esta llamada, el ERP no necesita actualizar el servicio.
Se recomienda almacenar el uniqueId devuelto por Logístiko para relacionar y consultar posteriormente el servicio.
2. Asignación y optimización
Logístiko se encarga de:
- Agrupar los servicios.
- Asignarlos a una ruta.
- Asignarlos a un conductor.
- Ordenar las paradas.
- Optimizar el recorrido.
En esta fase el ERP no interviene.
3. Despacho de la ruta
Cuando la planificación está preparada, un usuario despacha la ruta desde el panel de Logístiko.
La ruta queda disponible en la aplicación del conductor.
En este flujo no se envía al ERP el webhook de servicio asignado a ruta.
4. Ejecución de la ruta
Desde la aplicación, el conductor puede:
- Completar el formulario de inicio de ruta.
- Iniciar la ruta.
- Registrar la llegada a los destinos.
- Completar los servicios.
- Registrar incidencias.
- Completar el formulario de fin de ruta.
Logístiko almacena internamente los estados, fechas, coordenadas, observaciones y evidencias generadas durante la ejecución.
El ERP no recibe estas novedades automáticamente.
5. Consulta del estado
Para conocer el estado actual, el ERP debe consultar cada servicio mediante:
Obtener estado actual del servicio
La consulta puede realizarse periódicamente hasta que el servicio alcance un estado final.
Estrategia recomendada de consulta
La frecuencia de consulta debe adaptarse a las necesidades de la operativa.
Por ejemplo:
- Consultar con mayor frecuencia durante el horario de reparto.
- Reducir la frecuencia cuando el servicio todavía no está despachado.
- Dejar de consultar cuando el servicio haya alcanzado un estado final.
- Evitar consultar servicios cancelados o cerrados.
- Distribuir las consultas para no ejecutar todas las llamadas al mismo tiempo.
El sistema debe almacenar el último estado recibido y actualizarlo solamente cuando exista una novedad.
Diferencias respecto al uso de webhooks
| Webhooks | Consulta periódica |
|---|---|
| Logístiko inicia la comunicación | El ERP inicia la comunicación |
| Las novedades se reciben casi en tiempo real | La novedad se recibe en la siguiente consulta |
| Se realizan llamadas solo cuando existe un evento | Se realizan consultas aunque no existan cambios |
| Requiere un endpoint receptor público | No requiere exponer un endpoint receptor |
| Puede incluir información completa del evento | Devuelve el estado disponible en el endpoint de consulta |
flowchart TB
%% =========================
%% 1. CREACIÓN
%% =========================
subgraph P1["1. Creación única del servicio"]
direction LR
E1["ERP<br/>Documento finalizado"]
L1["Logístiko<br/>Crea el servicio"]
E1 -->|"POST Crear servicios"| L1
end
%% =========================
%% 2. PLANIFICACIÓN
%% =========================
subgraph P2["2. Asignación y optimización"]
direction RL
E2["ERP<br/>Sin intervención"]
subgraph O2[" "]
direction TB
L2["Logístiko<br/>Asigna, agrupa y optimiza<br/>los servicios"]
end
O2 ~~~ E2
end
%% =========================
%% 3. DESPACHO
%% =========================
subgraph P3["3. Despacho de la ruta"]
direction LR
E3["ERP<br/>No recibe webhook<br/>de despacho"]
subgraph O3[" "]
direction TB
L3["Logístiko<br/>Despacha la ruta<br/>desde el panel"]
A3["APP conductor<br/>Recibe la ruta"]
L3 -->|"Ruta despachada"| A3
end
E3 ~~~ O3
end
%% =========================
%% 4. OPERATIVA
%% =========================
subgraph P4["4. Operativa del conductor"]
direction LR
E4["ERP<br/>No recibe webhooks"]
subgraph O4[" "]
direction TB
A4A["APP conductor<br/>Completa el formulario<br/>de inicio de ruta"]
A4B["APP conductor<br/>Inicia la ruta"]
A4C["APP conductor<br/>Registra la llegada<br/>al destino"]
A4D["APP conductor<br/>Completa la entrega<br/>o registra una incidencia"]
A4E["APP conductor<br/>Completa el formulario<br/>de fin de ruta"]
L4["Logístiko<br/>Actualiza los estados,<br/>fechas y evidencias"]
A4A --> A4B
A4B --> A4C
A4C --> A4D
A4D --> A4E
A4E --> L4
end
E4 ~~~ O4
end
%% =========================
%% 5. CONSULTA DE ESTADO
%% =========================
subgraph P5["5. Consulta periódica del estado"]
direction LR
E5["ERP<br/>Consulta el estado<br/>de cada servicio"]
L5["Logístiko<br/>Devuelve el estado actual<br/>del servicio"]
E5 -->|"GET Obtener estado"| L5
L5 -.->|"Respuesta con el estado actual"| E5
end
%% Orden vertical
P1 ~~~ P2
P2 ~~~ P3
P3 ~~~ P4
P4 ~~~ P5
%% Colores
classDef erp fill:#15803d,stroke:#86efac,stroke-width:2px,color:#ffffff
classDef logistiko fill:#075985,stroke:#7dd3fc,stroke-width:2px,color:#ffffff
classDef app fill:#6d28d9,stroke:#c4b5fd,stroke-width:2px,color:#ffffff
classDef inactive fill:#374151,stroke:#6b7280,stroke-width:1px,color:#d1d5db
class E1,E5 erp
class E2,E3,E4 inactive
class L1,L2,L3,L4,L5 logistiko
class A3,A4A,A4B,A4C,A4D,A4E app
%% Contenedores
style P1 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P2 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P3 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P4 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P5 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style O2 fill:transparent,stroke:transparent,color:transparent
style O3 fill:transparent,stroke:transparent,color:transparent
style O4 fill:transparent,stroke:transparent,color:transparent
linkStyle default stroke:#94a3b8,stroke-width:2px
%% Documentación
click L1 "https://logistiko.readme.io/reference/servicios-crear" "Ver Crear servicios"
click E5 "https://logistiko.readme.io/reference/servicios-obtener-estado" "Ver Obtener estado del servicio"
click L5 "https://logistiko.readme.io/reference/servicios-obtener-estado" "Ver Obtener estado del servicio"
Flujo 3: creación como pedido, actualización a albarán y predespacho opcional
Este flujo se utiliza cuando el servicio se crea en Logístiko a partir de un pedido, antes de que el albarán definitivo esté disponible.
De esta forma, Logístiko puede comenzar la planificación anticipadamente. Cuando el ERP genera el albarán, actualiza el mismo servicio para sustituir la referencia del pedido por la referencia definitiva del albarán.
El webhook de predespacho es opcional. Solo debe utilizarse cuando el ERP necesite información de la asignación realizada por Logístiko para completar o recalcular los datos del servicio antes del despacho.
Cuándo utilizar este flujo
Este modelo es adecuado cuando:
- El ERP dispone inicialmente de un pedido, pero todavía no ha generado el albarán.
- Logístiko necesita recibir los servicios antes de la finalización del albarán para comenzar la planificación.
- El número de albarán todavía no existe en el momento de la creación.
- Los artículos, cantidades, pesos u otros datos pueden cambiar entre el pedido y el albarán.
- El ERP debe actualizar el servicio cuando se genere el documento definitivo.
- Opcionalmente, el ERP necesita conocer la ruta, el conductor, el vehículo, la posición o la hora estimada antes de completar la actualización.
- Los cambios deben estar disponibles antes de que la ruta llegue a la aplicación del conductor.
Descripción del flujo
1. Creación inicial como pedido
Cuando se genera el pedido, el ERP crea el servicio mediante:
La referencia principal enviada inicialmente corresponde al número de pedido.
También debe indicarse que el documento recibido es un pedido:
{
"albaran": "PED-2026-00125",
"documentoConcepto": "Pedido"
}En este momento, el servicio queda identificado en Logístiko mediante el número de pedido.
El ERP debe almacenar el uniqueId devuelto por Logístiko, ya que posteriormente permitirá actualizar exactamente el mismo servicio.
No debe crearse un segundo servicio cuando se genere el albarán. Debe actualizarse el servicio creado originalmente a partir del pedido.
2. Asignación y optimización
Logístiko puede comenzar la planificación utilizando la información disponible en el pedido.
La planificación puede incluir:
- Agrupación de servicios.
- Creación de rutas.
- Asignación de conductores.
- Asignación de vehículos.
- Ordenación de paradas.
- Optimización del recorrido.
- Cálculo de horas estimadas.
- Validación de capacidades.
En esta fase el documento todavía puede estar identificado como Pedido.
3. Webhook de predespacho opcional
El webhook de predespacho no es obligatorio en este flujo.
Solo debe configurarse cuando el ERP necesite conocer información de la planificación para actualizar o completar los servicios.
Por ejemplo, el ERP puede necesitar conocer:
- La ruta asignada.
- El conductor asignado.
- El vehículo.
- La matrícula.
- La posición del servicio dentro de la ruta.
- La hora estimada de llegada.
- La agrupación propuesta por Logístiko.
En ese caso, Logístiko envía:
El webhook de predespacho se envía antes del despacho de la ruta y puede contener varios servicios dentro de un array.
Ejemplo conceptual:
[
{
"uniqueId": "687000000000000000000001",
"serviceRef": "PED-2026-00125",
"serviceIdOrder": "PED-2026-00125",
"routeRef": "RUTA-15",
"driverCode": "CONDUCTOR-01",
"licensePlate": "1234-ABC",
"servicePos": 4,
"dateEstimated": 1784536200000,
"status": 40
}
]El ERP puede utilizar esta información para completar el albarán o recalcular datos dependientes de la planificación.
Cuándo no se necesita el predespacho
No es necesario utilizar este webhook cuando el ERP puede generar el albarán sin conocer la asignación realizada por Logístiko.
En ese caso, el flujo continúa directamente:
- Logístiko realiza la planificación.
- El ERP genera el albarán.
- El ERP actualiza el servicio mediante Actualizar servicio V2.
- Logístiko actualiza la planificación.
- La ruta se revisa y se despacha.
El predespacho es una comunicación informativa y opcional. No significa que la ruta ya esté disponible en la aplicación del conductor.
4. Actualización de pedido a albarán
Cuando el ERP genera el albarán definitivo, debe actualizar el servicio existente mediante:
La actualización debe realizarse preferentemente mediante el uniqueId obtenido durante la creación.
Para transformar el pedido en albarán deben actualizarse los siguientes campos:
| Campo | Valor | Comportamiento |
|---|---|---|
referenciaNueva | Número del albarán | Sustituye la referencia principal original del pedido |
referenciaExternaNueva | Número del pedido | Opcionalmente conserva el pedido como referencia externa |
documentoConcepto | Albaran | Cambia el concepto del documento de pedido a albarán |
Ejemplo:
{
"uniqueId": "687000000000000000000001",
"referenciaNueva": "ALB-2026-00457",
"referenciaExternaNueva": "PED-2026-00125",
"documentoConcepto": "Albaran"
}Después de procesar esta actualización:
- La referencia principal del servicio pasa a ser
ALB-2026-00457. - El número de pedido original deja de ser la referencia principal.
- Si se informa
referenciaExternaNueva, el pedido queda guardado como referencia externa. - El concepto del documento pasa de
PedidoaAlbaran. - Se mantiene el mismo servicio y el mismo
uniqueId.
Resultado conceptual
Antes de la actualización:
Referencia principal: PED-2026-00125
Referencia externa: -
Documento: PedidoDespués de la actualización:
Referencia principal: ALB-2026-00457
Referencia externa: PED-2026-00125
Documento: AlbaranreferenciaExternaNueva es opcional.
Debe informarse cuando se quiera conservar el número de pedido dentro de Logístiko como referencia auxiliar para:
- Consultas.
- Búsquedas.
- Trazabilidad.
- Relación entre pedido y albarán.
- Integraciones posteriores.
Si no se necesita conservar el número de pedido, puede omitirse.
5. Actualización de artículos
Los artículos también pueden actualizarse cuando hayan cambiado entre el pedido y el albarán.
Esto puede ocurrir cuando:
- Se modifica la cantidad servida.
- Se elimina algún artículo.
- Se añade un artículo.
- Cambia el peso.
- Cambia el número de unidades.
- Se sustituuye un artículo.
- Se modifica el código o descripción.
- Cambian los bultos asociados.
- El albarán contiene solamente una parte del pedido original.
La actualización del servicio puede incluir conjuntamente:
- El nuevo número de albarán.
- La referencia externa del pedido.
- El nuevo concepto del documento.
- Los artículos definitivos.
- Las cantidades definitivas.
- Los pesos definitivos.
- Los bultos definitivos.
- Los importes o datos de cobro actualizados.
Ejemplo conceptual:
{
"uniqueId": "687000000000000000000001",
"referenciaNueva": "ALB-2026-00457",
"referenciaExternaNueva": "PED-2026-00125",
"documentoConcepto": "Albaran",
"cantidad": 8,
"peso": 124.5
}La estructura concreta de los artículos debe enviarse utilizando los campos admitidos por Actualizar servicio V2.
Cuando se actualicen listas de artículos o bultos, debe respetarse el comportamiento definido por el endpoint para evitar eliminar información que no se haya incluido en la actualización.
6. Actualización de la planificación
Después de recibir los cambios del ERP, la planificación debe actualizarse en Logístiko.
Este paso permite que la ruta utilice los datos definitivos del albarán.
Es especialmente importante cuando se hayan modificado datos que puedan afectar a la planificación:
- Cantidad.
- Peso.
- Volumen.
- Número de bultos.
- Horarios.
- Duración de parada.
- Dirección.
- Prioridad.
- Artículos.
- Restricciones operativas.
Si los cambios afectan a la capacidad, los horarios o las condiciones de entrega, puede ser necesario revisar o recalcular la planificación.
La ruta no debe despacharse hasta confirmar que las actualizaciones enviadas por el ERP se han procesado correctamente.
Si la ruta se despacha antes de finalizar la actualización, la aplicación del conductor podría recibir el número de pedido original, artículos anteriores o información incompleta.
7. Despacho de la ruta
Una vez actualizados los servicios y revisada la planificación, la ruta se despacha desde el panel de Logístiko.
Como resultado:
- La ruta queda disponible en la aplicación del conductor.
- El conductor recibe los datos definitivos del albarán.
- Logístiko envía al ERP el webhook de servicio asignado a ruta.
Documentación:
Webhook de servicio asignado a ruta
Este webhook representa la asignación finalmente despachada.
No debe confundirse con el webhook de predespacho:
| Webhook de predespacho | Webhook de servicio asignado a ruta |
|---|---|
| Es opcional | Forma parte del seguimiento del despacho cuando está configurado |
| Se envía antes de actualizar los servicios | Se envía después del despacho |
| Comunica una planificación propuesta | Comunica la asignación finalmente despachada |
| Permite al ERP actualizar información | La ruta ya está disponible en la aplicación |
| Puede cambiar antes del despacho | Representa el resultado final del despacho |
8. Inicio de la ruta
Antes de iniciar el recorrido, el conductor puede completar el formulario de inicio de ruta.
Logístiko puede enviar:
Webhook del formulario de inicio de ruta
Cuando el conductor inicia la ruta desde la aplicación, Logístiko envía:
El formulario de inicio y el inicio efectivo de la ruta son eventos diferentes.
9. Ejecución de los servicios
Cuando el conductor registra la llegada al destino, Logístiko envía:
Después de la llegada, el servicio puede finalizar de distintas formas.
Servicio completado
Cuando el conductor completa correctamente el servicio, Logístiko envía:
Webhook de servicio completado
Servicio con incidencia
Cuando el conductor registra una incidencia, Logístiko envía:
Webhook de servicio con incidencia
Estado forzado
Cuando el estado del servicio se modifica de forma excepcional, Logístiko puede enviar:
10. Fin de la ruta
Cuando el conductor completa el formulario final, Logístiko envía:
Webhook del formulario de fin de ruta
Resumen de las dos variantes
Variante A: el ERP no necesita información de la asignación
ERP crea el servicio como Pedido
→ Logístiko planifica
→ ERP genera el albarán
→ ERP actualiza Pedido a Albaran
→ Logístiko actualiza la planificación
→ Logístiko despacha la ruta
→ La ruta llega a la aplicaciónEn esta variante no se utiliza el webhook de predespacho.
Variante B: el ERP necesita información de la asignación
ERP crea el servicio como Pedido
→ Logístiko planifica
→ Logístiko envía el webhook de predespacho
→ ERP utiliza la asignación para generar o completar el albarán
→ ERP actualiza Pedido a Albaran
→ Logístiko actualiza la planificación
→ Logístiko despacha la ruta
→ La ruta llega a la aplicaciónEn esta variante el webhook de predespacho permite al ERP utilizar datos de la planificación antes de actualizar el servicio.
Consideraciones de integración
El ERP debe:
- Almacenar el
uniqueIdobtenido durante la creación. - Actualizar el servicio existente en lugar de crear otro.
- Enviar
referenciaNuevacon el número del albarán. - Enviar opcionalmente
referenciaExternaNuevacon el número del pedido. - Cambiar
documentoConceptodePedidoaAlbaran. - Actualizar los artículos cuando existan diferencias.
- Procesar el webhook de predespacho únicamente si necesita datos de la asignación.
- No interpretar el predespacho como confirmación de despacho.
- Esperar a que las actualizaciones terminen antes de despachar la ruta.
- Procesar los webhooks de forma idempotente.
flowchart TB
%% =========================
%% 1. CREACIÓN COMO PEDIDO
%% =========================
subgraph P1["1. Creación inicial como pedido"]
direction LR
E1["ERP<br/>Genera el pedido"]
L1["Logístiko<br/>Crea el servicio con<br/>documentoConcepto = 'Pedido'"]
E1 -->|"POST Crear servicios"| L1
end
%% =========================
%% 2. PLANIFICACIÓN Y PREDESPACHO OPCIONAL
%% =========================
subgraph P2["2. Planificación y predespacho opcional"]
direction RL
E2["ERP<br/>Continúa con la generación<br/>o finalización del albarán"]
subgraph O2[" "]
direction TB
L2A["Logístiko<br/>Asigna y optimiza<br/>los servicios"]
D2{"¿El ERP necesita información<br/>de la asignación para<br/>actualizar los servicios?"}
L2B["Logístiko<br/>Envía el webhook<br/>de predespacho"]
L2A --> D2
D2 -->|"Sí"| L2B
end
L2B -->|"POST Webhook de predespacho<br/>(opcional)"| E2
D2 -.->|"No necesita la asignación"| E2
end
%% =========================
%% 3. PEDIDO A ALBARÁN
%% =========================
subgraph P3["3. Actualización de pedido a albarán"]
direction LR
E3["ERP<br/>Finaliza el albarán y actualiza:<br/>referenciaNueva = nº de albarán<br/>referenciaExternaNueva = nº de pedido (opcional)<br/>documentoConcepto = 'Albaran'<br/>Artículos actualizados si han cambiado"]
L3["Logístiko<br/>Actualiza el mismo servicio<br/>y sustituye la referencia<br/>principal del pedido"]
E3 -->|"POST Actualizar servicio V2"| L3
end
%% =========================
%% 4. REVISIÓN Y DESPACHO
%% =========================
subgraph P4["4. Actualización de la planificación y despacho"]
direction RL
E4["ERP<br/>Recibe la asignación<br/>finalmente despachada"]
subgraph O4[" "]
direction TB
L4A["Logístiko<br/>Actualiza la planificación<br/>con los cambios del ERP"]
L4B["Logístiko<br/>Revisa y despacha<br/>la ruta desde el panel"]
A4["APP conductor<br/>Recibe la ruta"]
L4C["Logístiko<br/>Envía el webhook de<br/>servicio asignado a ruta"]
L4A --> L4B
L4B -->|"Ruta despachada"| A4
L4B --> L4C
end
O4 -->|"POST Webhook de despacho"| E4
end
%% =========================
%% 5. INICIO DE RUTA
%% =========================
subgraph P5["5. Inicio de ruta"]
direction RL
E5["ERP<br/>Recibe los eventos<br/>de inicio de ruta"]
subgraph O5[" "]
direction TB
A5F["APP conductor<br/>Completa el formulario<br/>de inicio de ruta"]
L5F["Logístiko<br/>Envía el webhook del<br/>formulario de inicio"]
A5S["APP conductor<br/>Inicia la ruta"]
L5S["Logístiko<br/>Envía el webhook<br/>de ruta iniciada"]
A5F --> L5F
L5F --> A5S
A5S --> L5S
end
O5 -->|"POST Webhooks de inicio"| E5
end
%% =========================
%% 6. OPERATIVA DEL SERVICIO
%% =========================
subgraph P6["6. Operativa por servicio"]
direction RL
E6["ERP<br/>Recibe los eventos<br/>del servicio"]
subgraph O6[" "]
direction TB
A6A["APP conductor<br/>Registra la llegada<br/>al destino"]
L6A["Logístiko<br/>Envía el webhook<br/>de llegada al destino"]
D6{"Resultado<br/>del servicio"}
A6E["APP conductor<br/>Completa la entrega"]
L6E["Logístiko<br/>Envía el webhook<br/>de servicio completado"]
A6I["APP conductor<br/>Registra una incidencia"]
L6I["Logístiko<br/>Envía el webhook<br/>de incidencia"]
X6["Acción excepcional<br/>Se fuerza el estado<br/>del servicio"]
L6F["Logístiko<br/>Envía el webhook<br/>de estado forzado"]
A6A --> L6A
L6A --> D6
D6 -->|"Entregado"| A6E
A6E --> L6E
D6 -->|"Incidencia"| A6I
A6I --> L6I
D6 -.->|"Opcional"| X6
X6 --> L6F
end
O6 -->|"POST Webhooks de servicio"| E6
end
%% =========================
%% 7. FIN DE RUTA
%% =========================
subgraph P7["7. Fin de ruta"]
direction RL
E7["ERP<br/>Recibe el formulario<br/>de fin de ruta"]
subgraph O7[" "]
direction TB
A7["APP conductor<br/>Completa el formulario<br/>de fin de ruta"]
L7["Logístiko<br/>Envía el webhook del<br/>formulario de fin de ruta"]
A7 --> L7
end
O7 -->|"POST Webhook de fin de ruta"| E7
end
%% Orden vertical
P1 ~~~ P2
P2 ~~~ P3
P3 ~~~ P4
P4 ~~~ P5
P5 ~~~ P6
P6 ~~~ P7
%% Colores
classDef erp fill:#15803d,stroke:#86efac,stroke-width:2px,color:#ffffff
classDef logistiko fill:#075985,stroke:#7dd3fc,stroke-width:2px,color:#ffffff
classDef app fill:#6d28d9,stroke:#c4b5fd,stroke-width:2px,color:#ffffff
classDef decision fill:#4c1d95,stroke:#c4b5fd,stroke-width:2px,color:#ffffff
classDef optional fill:#78350f,stroke:#fbbf24,stroke-width:2px,color:#ffffff
class E1,E2,E3,E4,E5,E6,E7 erp
class L1,L2A,L2B,L3,L4A,L4B,L4C,L5F,L5S,L6A,L6E,L6I,L6F,L7 logistiko
class A4,A5F,A5S,A6A,A6E,A6I,A7 app
class D2,D6 decision
class X6 optional
%% Contenedores
style P1 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P2 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P3 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P4 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P5 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P6 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style P7 fill:#111827,stroke:#475569,stroke-width:1px,color:#f8fafc
style O2 fill:transparent,stroke:transparent,color:transparent
style O4 fill:transparent,stroke:transparent,color:transparent
style O5 fill:transparent,stroke:transparent,color:transparent
style O6 fill:transparent,stroke:transparent,color:transparent
style O7 fill:transparent,stroke:transparent,color:transparent
linkStyle default stroke:#94a3b8,stroke-width:2px
%% Documentación
click L1 "https://logistiko.readme.io/reference/servicios-crear" "Ver Crear servicios"
click L2B "https://logistiko.readme.io/reference/webhookpredispatch" "Ver webhook de predespacho"
click E3 "https://logistiko.readme.io/reference/actualizar-servicio-v2" "Ver Actualizar servicio V2"
click L3 "https://logistiko.readme.io/reference/actualizar-servicio-v2" "Ver Actualizar servicio V2"
click L4C "https://logistiko.readme.io/reference/webhookserviceassignedtoroute" "Ver webhook de servicio asignado a ruta"
click L5F "https://logistiko.readme.io/reference/webhookroutestartform" "Ver webhook del formulario de inicio"
click L5S "https://logistiko.readme.io/reference/webhookroutestarted" "Ver webhook de ruta iniciada"
click L6A "https://logistiko.readme.io/reference/webhookservicearrived" "Ver webhook de llegada al destino"
click L6E "https://logistiko.readme.io/reference/webhookservicecompleted" "Ver webhook de servicio completado"
click L6I "https://logistiko.readme.io/reference/webhookserviceincidence" "Ver webhook de incidencia"
click L6F "https://logistiko.readme.io/reference/webhookserviceforcedstatus" "Ver webhook de estado forzado"
click L7 "https://logistiko.readme.io/reference/webhookrouteendform" "Ver webhook del formulario de fin de ruta"
Updated 26 days ago