{"id":139,"date":"2026-10-18T09:00:00","date_gmt":"2026-10-18T07:00:00","guid":{"rendered":"https:\/\/yindle.com\/?p=139"},"modified":"2026-09-21T22:09:31","modified_gmt":"2026-09-21T20:09:31","slug":"trackpod-route-update-veilig-verwerken","status":"publish","type":"post","link":"https:\/\/yindle.com\/en\/processing-track-pod-route-updates-without-reversing-statuses\/","title":{"rendered":"Processing Track-POD route updates without reversing statuses"},"content":{"rendered":"

Process a complete route update as a validated snapshot and protect every derived field from older events<\/a>. A separate ETA or status update received later may concern an earlier state than the route snapshot. Without version checks, a delivery stop may revert from delivered to on the way, or an old route may appear current again.<\/p>\n

A route webhook contains relationships<\/h2>\n

A route is more than a list of separate stops. Vehicle, sequence, planned date and stop identities together form the plan. First check that the snapshot belongs to the correct workspace, route and date, and that every record is valid. Only then project the relevant fields onto local delivery stops or the ERP.<\/p>\n

A complete snapshot must not automatically treat missing stops as deleted. Determine whether the provider actually sent a complete authoritative route and whether the local route is still the same version. Deletion or unlinking is safe only when the received route demonstrably represents the current route.<\/p>\n

Use a clock for each field<\/h2>\n

One general \u2018last updated\u2019 time is too broad. Status, ETA, vehicle and trip sequence may come from different events. For each relevant field, retain which provider event or version was last applied. A newer ETA may change the current arrival estimate without restoring an older status; a delivered status must not disappear because an outdated route snapshot arrives later.<\/p>\n

\n\n\n\n\n\n\n\n\n
Field<\/th>\nLikely source<\/th>\nProtect against<\/th>\n<\/tr>\n<\/thead>\n
Status<\/td>\nStop or order event<\/td>\nOlder route projection<\/td>\n<\/tr>\n
ETA<\/td>\nLive route event<\/td>\nOutdated estimate<\/td>\n<\/tr>\n
Vehicle<\/td>\nComplete route<\/td>\nSnapshot of the previous plan<\/td>\n<\/tr>\n
Sequence<\/td>\nComplete route<\/td>\nPartial update without context<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

This projection can form part of a configurable flow in Connect<\/a>.<\/p>\n

Fictional example: delivered is not reversed<\/h2>\n

Fictional example: route R-18 is refreshed at 15:10; stop 7 is assigned vehicle Bus 2 and position 4. At 15:42, a stop event reports that order 9087 has been delivered. Due to network delay, a route snapshot arrives at 15:50 that was created at 15:30 and shows the stop as on the way.<\/p>\n

The integration still uses the snapshot for fields for which it is recent enough, but compares the status clock. \u2018Delivered\u2019 from 15:42 remains. The older snapshot does not reactivate the stop. If an entirely new route from 16:00 demonstrably moved the stop to another vehicle, the vehicle and sequence could change according to their own versions. This fictional example explains why one record timestamp is insufficient.<\/p>\n

Route projection checklist<\/h2>\n