Privacy Policy

1. Who we are

TrackMaestro is a last-mile delivery tracking and management platform. Logistics companies ("tenants") use it to manage packages, coordinate drivers, capture proof of delivery, and keep their customers informed. The platform is operated by Xandr Studios ("TrackMaestro", "we", "us"), based in Ontario, Canada.

The platform consists of a marketing website (trackmaestro.co), a tenant operations console, a driver web app and native iOS/Android driver app, a public package-tracking page, an internal platform-administration console, and the API that serves them. Your use of the platform is also governed by our Terms of Service.

2. Our role, and who this policy covers

TrackMaestro handles personal information in two distinct roles. Which one applies determines who you should contact about your information.

As a controller

For our marketing website, early-access and contact enquiries, tenant accounts, the users a tenant invites, billing records, and our own security and audit logs, we decide why and how information is used. This policy governs that use.

As a processor (service provider)

For delivery data a tenant loads into the platform (their customers, addresses, packages, manifests, proof of delivery, notifications, and AI call records), the tenant is the controller. We process that information on their instructions, under our agreement with them. If you received a delivery and want your information corrected or deleted, contact the delivery company that shipped it; we will assist them, but we cannot act on their data without their instruction.

This policy applies to: visitors to our website; tenant owners, administrators, dispatchers and billing managers; drivers using the driver web app or native mobile app; and delivery recipients who open a tracking link or receive delivery notifications.

3. Website visitors and early access

Our marketing website is a server-rendered page with no analytics, no advertising tags, no session recording, and no tracking pixels. It sets no cookies of its own and does not build a profile of you.

• Early-access requests: if you submit the early-access form we receive your full name, work email, company, team size, and (optionally) the delivery challenge you describe. We use it only to contact you about early access and product availability.
• Enquiries: if you email the address on this site, we receive your message and whatever it contains.
• Server logs: our hosting provider records standard request data (IP address, user agent, requested URL, timestamp) for delivery, abuse prevention, and troubleshooting.
• Web fonts: the site loads the Inter typeface from Google Fonts, so your browser makes a request to Google’s servers, which reveals your IP address and user agent to Google. No font-related cookie is set.

4. Account and user information

When a tenant is provisioned and when a tenant invites users (administrators, dispatchers, billing managers, drivers), we hold the information needed to create and secure those accounts:

• Identity and contact details: name, email address, phone number, role, and tenant, plus company details such as legal name, country, region, city, time zone, locale, and unit preferences.
• Authentication material: a hashed password (never the password itself), password history and expiry state, TOTP secrets and backup codes where multi-factor authentication is enabled, and registered passkeys/WebAuthn credentials.
• Biometric sign-in (native app only): a device credential generated on your phone. The raw credential stays in the device Keychain or Android encrypted storage; our API stores only an HMAC hash of it, rotates it after every use, and expires it after 30 days by default. We never receive your fingerprint or face data. The biometric check happens entirely on your device, and the operating system never shares the biometric itself with any app.
• Session and security context: bearer-token session state, sign-in events, IP address, optional IP allowlists, and request identifiers.
• Audit records: privileged actions in the tenant and platform consoles, including any support impersonation session, which is explicitly audited, are logged with the acting user, action, and timestamp.
• API keys: keys a tenant issues for its own integrations are stored one-way hashed and cannot be recovered after creation.

5. Delivery data loaded by tenants

Tenants create packages individually, import them in bulk by CSV, or push them through the API. That data is theirs; we hold and process it on their behalf.

• Recipient details: name, email address, phone number, delivery address (country-aware, including Canadian and US postal formats and Jamaican parish/community formats), resolved geographic coordinates, and any delivery notes or access instructions the tenant supplies.
• Package details: tracking number, carrier, weight, external reference, status history, and exception reasons such as delayed, failed, damaged, or incomplete.
• Manifests and routing: stop sequences, driver assignments, route lifecycle events, and estimated arrival information.
• Delivery location corrections: where a driver proposes a more precise drop-off point for an address, the proposed coordinates and the tenant’s review of them.

Tenants are responsible for having a lawful basis to load recipient information into TrackMaestro and for telling their own customers how that information is used.

6. Driver information and location

Drivers use either the driver web app or the native iOS/Android app. Both connect to the same API and are visible to their employing tenant, not to other tenants.

What we collect from drivers

• Profile and assignment data: name, email, phone, vehicle name and plate, status, assigned manifests, and completed stop activity.
• Precise location, while a route is in progress (see below).
• Device push tokens, so the app can receive manifest and package notifications.
• Locally queued work: when the app is offline, pending status updates and proof photos are stored on the device (IndexedDB in the web app, SQLite in the native app) and uploaded in order when connectivity returns. They are held on the device until the server accepts them.

How location sharing works

• Location permission is requested only when a driver starts or resumes an active route, never at first launch or at sign-in.
• Tracking runs only while a manifest is in progress. It stops immediately when the route is completed or cancelled, when the driver is unassigned, and on sign-out. After an app restart it resumes only if the route is still in progress and permission was already granted.
• On Android, tracking runs as a foreground service with a persistent, visible notification. On iOS, the system location indicator is shown while tracking is active.
• Updates are battery-conscious: the first good fix publishes immediately, then updates follow roughly a 30 m distance filter plus a 20-second heartbeat. Through a connectivity loss only the single latest position is retained; stale points are never accumulated or replayed.
• Declining the permission does not block delivery work; the driver simply appears without live location.

What delivery recipients can see

• The full route is never exposed on a public tracking page.
• By default the map shows only a coarse delivery-area circle, with a tenant-configurable privacy radius. Tenants can also switch the map off entirely.
• A live driver marker is opt-in per tenant and, when enabled, only appears once the driver is nearby, never earlier in the route and never after delivery. Its coordinates are coarsened on the server (approximately 110 m) so it conveys approach without pinpointing the driver.
• The "nearby" decision is made on the server from a fresh, sufficiently accurate fix. Stale or low-accuracy positions never reveal the marker. The browser is not trusted with this decision.

7. Proof of delivery

Where a tenant requires it, drivers capture proof at the point of delivery: a photograph, an on-screen signature, a recipient name, notes, a timestamp, and delivery confirmation. Photographs are compressed on the device and uploaded to protected, tenant-scoped object storage; the delivery record references the stored file rather than embedding it.

Which of these are required is configured by the tenant. Proof files are subject to the retention rules described below; when a proof record is purged, the underlying stored object is deleted with it.

8. AI delivery calls

Where a tenant has the feature enabled, a driver can place an AI voice call to a recipient from a stop, for example to confirm someone is home, resolve building access, or ask permission to leave a package. Calls are always initiated by a driver at a specific stop; they are never placed automatically and are never queued for later.

• Calls are carried by our AI voice provider over a platform-owned telephone number. The provider processes the call audio to conduct the conversation.
• We retain call metadata (time, duration, outcome, status, cost) and, where enabled, a transcript and a reference to a recording. Transcripts and recordings are read-restricted by role and are not shown in ordinary delivery views.
• Destination phone numbers on call and SMS records are stored masked for display and one-way hashed for correlation, not in the clear.
• A platform-wide redaction window applies: once it elapses after a call ends, the retention worker clears the transcript and the recording reference. Platform operators can also disable AI calling outright.

Call recording and monitoring laws vary by province, state, and country, and several require the consent of one or all parties. Tenants are responsible for enabling recording only where it is lawful for them, and for making any disclosure their jurisdiction requires.

9. Notifications and tracking links

• Email and SMS: tenants can notify their customers about delivery progress. We process the destination address or number to send the message and keep a delivery receipt. SMS destinations are stored masked and hashed.
• Browser push: on a public tracking page, a customer can explicitly opt in to Web Push alerts for "driver nearby" and "delivered". The subscription is standards-based; the tracking destination is stored only in that browser by the service worker, and our API never stores the raw tracking token. Push stays disabled unless the platform has push keys configured, and tenants can turn either alert off.
• Mobile push for drivers: the native app registers a device token to receive manifest assigned, unassigned, and cancelled notifications, and packages added or removed. The token is deleted when the driver signs out.
• Tracking links: a tracking link is a one-time public URL. It exposes only the privacy-limited view described above. The tracking app sends no referrer, is served no-store, and is blocked from search indexing so links are not crawled or cached.
• iOS Live Activity: an active route can show progress on the Lock Screen and Dynamic Island. It deliberately shows only the manifest number and stop counts, never a customer name, phone number, or address.

10. Mobile app permissions and privacy mode

The native driver app requests only the permissions the delivery workflow needs, at the moment it needs them:

Location (while using the app, and in the background)

Requested when a route is started or resumed, to share progress with dispatch and to support proximity-based customer updates. Stops when the route ends or the driver signs out.

Camera and photo library

Used only to capture proof-of-delivery photographs at a stop.

Notifications

Used for route and manifest updates, and for the Android tracking notification required while location sharing is active.

Biometrics (optional)

Used for biometric sign-in if the driver turns it on and the tenant’s policy allows it. The check happens on the device; no biometric data reaches our servers.

Tenants can additionally enable privacy mode for the mobile app. When it is on, selected fields (recipient name, phone, email, address, map, tracking details, notes, and proof) remain readable while the driver needs them to finish the stop and for a short configurable grace period afterwards, then are redacted on screen. While protected information is visible, the app blocks screenshots and hides its contents in the app switcher.

Session tokens and device credentials are stored in the platform keystore (iOS Keychain, Android encrypted storage), never in plain preferences.

11. Billing information

Subscriptions and usage-based charges are processed by our payment provider. Card details are entered directly with that provider and are never stored by, or transmitted through, TrackMaestro’s own systems. We retain the billing contact, plan and entitlement state, usage counts, invoices, transactions, refunds, and the provider’s payment-method reference, which is enough to bill accurately and answer billing questions.

12. How we use information, and our legal bases

We do not sell personal information, do not share it for cross-context behavioural advertising, and do not use delivery data to train third-party AI models beyond what is needed to conduct an AI delivery call the driver has placed.

13. Automated decision-making

We do not make decisions with legal or similarly significant effects about you by automated means alone. AI delivery calls are started by a driver, are visible to the tenant while in progress, and produce a suggested outcome that a person can review; route and dispatch tools propose sequencing that dispatchers and drivers remain free to change.

14. Who we share information with

We share personal information only with the service providers needed to run the platform, and only with what each of them needs. All are bound by contract to protect it and to use it solely to provide their service to us.

The exact providers in use are configured by our platform operators and may change; we will keep this list current. We may also disclose information when required by law or valid legal process, to establish or defend legal claims, or to protect the rights and safety of users and the public. If the business is involved in a merger, acquisition, or sale of assets, information may transfer as part of that transaction, subject to this policy.

Tenants are strictly isolated from one another: access is scoped from the signed-in session, and no tenant can see another tenant’s data.

15. International transfers

We are based in Canada and our providers may process information in Canada, the United States, and the European Union. Where information is transferred out of the UK or the European Economic Area, we rely on an adequacy decision or on Standard Contractual Clauses together with appropriate safeguards. You can ask us for details of the mechanism that applies to a specific transfer.

16. How long we keep information

Retention is enforced by a scheduled worker against per-category policies. A category can be kept indefinitely or deleted after a set window; where a rule’s purge is enabled, records older than the window are deleted permanently.

• Proof files: delivery photos and signatures, including the stored object itself.
• AI call records: logs, transcripts, and recording references, with an additional earlier redaction deadline for the transcript and recording.
• SMS delivery records: outbound delivery receipts, with destinations already masked and hashed.
• Delivery location corrections: proposed driver coordinates and the tenant’s review history.
• Packages, manifests, client records, and tracking links.
• Audit logs of privileged platform and tenant activity.

Tenants may be offered a longer retention window as a paid add-on; where that applies, their data is kept for the extended window instead of the default. Account and billing records are kept for as long as the account is active and afterwards as required for tax, accounting, and legal purposes. When a tenant account is destroyed at the tenant’s request, the deletion is irreversible and requires explicit confirmation. Residual copies may persist in encrypted backups for a limited period before being overwritten.

17. How we protect information

• Transport encryption for all traffic between apps, the API, and providers.
• Passwords, API keys, and biometric device credentials are stored one-way hashed; provider credentials such as payment and AI-voice keys are encrypted at rest and are write-only in the admin console.
• Multi-factor authentication, passkeys/WebAuthn, password policy and expiry, automatic sign-out on session expiry, and optional IP allowlisting.
• Role-based access control, strict tenant scoping derived from the session rather than from client input, and audit logging of privileged actions including support impersonation.
• Privacy-sensitive decisions, such as whether a driver is "nearby", how much of a location to reveal, and what a tracking page may show, are made on the server, not in the browser.
• Secrets are never shipped in browser bundles. The only map credential exposed to a browser is a public token restricted by URL and scope, which the map provider requires in every tile request.

No system is perfectly secure, but if a breach affects your personal information we will notify you and the applicable regulators where the law requires it.

18. Cookies and local storage

Our marketing website sets no cookies and runs no analytics, advertising, or tracking scripts, so there is no consent banner to dismiss.

The signed-in applications use strictly necessary browser storage to work: session state to keep you signed in, an on-device queue so drivers can keep working offline, a service worker to support installation and Web Push, and a locally stored tracking destination if a customer opts in to alerts. None of this is used for advertising or cross-site tracking. Clearing site data signs you out and discards anything queued locally.

19. Your rights and choices

Depending on where you live, you may have the right to access the personal information we hold about you, to correct it, to delete it, to receive a portable copy, to object to or restrict certain processing, to withdraw consent you have given, and not to be discriminated against for exercising these rights. These rights exist under Canadian privacy law (including PIPEDA and Quebec’s Law 25), the UK and EU GDPR, and US state privacy laws such as the CCPA/CPRA.

• If you are a tenant user or a website visitor, contact us using the details below and we will respond within the time the applicable law allows.
• If you are a delivery recipient, the delivery company that shipped your package controls your information. Contact them first; we will support their response as their processor.
• You can withdraw notification consent at any time: decline or revoke browser push in your browser settings, and use the unsubscribe or opt-out instructions in the messages you receive.
• Drivers can revoke location, camera, notification, and biometric permissions in device settings. Revoking location does not prevent completing deliveries.

We will ask you to verify your identity before acting on a request. If you are in the UK or EEA you may also complain to your local supervisory authority; in Canada, to the Office of the Privacy Commissioner or your provincial regulator.

20. Children

TrackMaestro is a business tool and is not directed to children. We do not knowingly collect personal information from anyone under 16. If you believe a child has provided us with information, contact us and we will delete it.

21. Changes to this policy

We may update this policy as the platform develops. The effective date at the top of the page always reflects the current version, and we will give tenants advance notice of material changes through the platform or by email.

22. Contact us

For privacy questions, requests, or complaints about how TrackMaestro handles personal information:

If your question is about a specific delivery or a package addressed to you, please contact the delivery company that sent it. They hold that information and decide how it is used.