Tutorials/Advanced
Advanced90 minREST + Web

Track a delivery with a trustworthy ETA

Join asset telemetry, map matching, route progress, ETA refresh, and customer visibility.

By the endA stateful live-delivery journey with recovery and replay.

Build against an explicit contract

A customer tracking page must show a useful ETA while the operations system retains authoritative trip state and late telemetry evidence.

A Mappls developer projectA restricted REST applicationFixture data with no production credentialsA request, aggregate, or correlation ID strategy
Step 1

Define the user and system contract

A customer tracking page must show a useful ETA while the operations system retains authoritative trip state and late telemetry evidence. Record the region, data freshness, latency budget, privacy purpose, credential owner, and fallback before choosing an SDK or endpoint.

Step 2

Create a durable trip identity

Bind order, route revision, provider trip, vehicle, and customer-safe tracking token before telemetry begins.

InTouch Telematics · SDK or product slice
type AssetEvent = {
  id: string;
  assetId: string;
  occurredAt: string;
  type: "position" | "ignition" | "geofence.entered" | "geofence.exited";
  position?: { latitude: number; longitude: number; speedKph?: number };
};

export async function handleAssetEvent(event: AssetEvent) {
  // Idempotency matters: delivery may be retried.
  if (await events.exists(event.id)) return;
  await events.transaction(async () => {
    await events.record(event);
    await assets.apply(event.assetId, event);
  });
}
Step 3

Process observations by event time

Deduplicate source events, store event and receipt time, reject state regression, map-match bounded fixes, and derive a new ETA revision only from eligible evidence.

Step 4

Separate customer view from control state

Expose coarse progress and freshness without driver secrets or full history. Route exceptions to an owned operations queue before changing the promise.

Step 5

Prove the production behavior

Automate the happy path and every named failure. The release is ready only when duplicate telemetry has one effect; late evidence remains auditable without rewinding progress; closure requires provider acknowledgement and delivery proof. Capture provider request identity without logging credentials or unnecessary precise location.

Failure modes you must exercise

telemetry silence

Fail fast with a typed, user-safe outcome and preserve the original request identity.

route deviation or closed road

Keep the last verified state, mark freshness honestly, and retry only within the documented idempotency boundary.

provider close succeeds after local timeout

Reconcile durable local and provider evidence before declaring success or issuing a compensating command.

Never turn uncertainty into success

Timeout after a stateful command is an unknown outcome. Query by provider/idempotency identity or wait for authoritative events; do not blindly retry a new command.

Definition of done

duplicate telemetry has one effectlate evidence remains auditable without rewinding progressclosure requires provider acknowledgement and delivery proof

REST production checks

Credentials never reach a browser or mobile bundleTimeout, retry, and idempotency policies are explicitCoordinates, addresses, and identifiers have data-retention rulesEvery operation is attributable in logs and usage reporting

Continue from source, contracts, and a full app

These links resolve to repository-derived evidence; unsupported package names and endpoints are not filled in from guesswork.

Study the complete Connected fleet trip state machine

Run it, break it, then observe it

Start with fixture credentials, execute the failure plan, and use request logs, usage, webhook evidence, and operational metrics before promoting traffic.