Loadout · Privacy

The short version

Loadout runs in the dispatcher's own browser. Driver names, emails, mobile numbers and photos stay on that computer. What this server keeps is who our customer is (the DSP owner's contact details and the company's), a credential for each computer, the DSP's Sling sign-in, encrypted, and, if backup is on, an already-pseudonymised copy of the dispatcher's own working notes. The week it passes along to be compared with Sling is pseudonymised too; the one exception is described under Reconciling with Sling. For the Driver portal, it also keeps each current driver's first name and last initial — "Juan P." — and nothing longer.

What this server stores

• Licence. The DSP company name, the plan, the expiry date, and how many computers are allowed. The licence is the owner's account: there is no shared licence key.
• The owner's account. The DSP owner's name, email and mobile number — the owner signs in with one code sent to that email and another texted to that mobile, and has no password — and the company's legal name, DSP code, station, business address and time zone. That is our customer, not their drivers: no driver is ever part of it. Sign-in codes are stored only as a keyed hash (HMAC) that a copy of the database alone cannot reverse, work once and expire after 10 minutes. Everything travels over HTTPS only; plain HTTP is refused, and no response is cached.
• Computers. A random UUID generated by the browser, the name the owner gives it ("Dispatch desk"), how it was added, the extension version and when it was last seen, plus the SHA-256 of its own credential. It is not a hardware identifier and it does not follow anyone between products. The owner sees this list and can remove any computer from it.
• The DSP's Sling sign-in. The session Loadout uses to read the DSP's Sling account, stored encrypted, with when it was last renewed and whether it still works. It is never shown back. See Sling below.
• Usage counts. How many times the extension checked its licence, saved a backup, had the schedule compared with Sling or asked the assistant a question. Counts only — never what was asked or what came back.
• Backup, if enabled. The dispatcher's own working notes, with every person reduced to a one-way hash of their work email before anything leaves the browser. Names, phone numbers, Transporter and provider IDs, photos and private notes are deleted at that boundary, not masked — a masked name is still a name. All of it, and nothing else:
  • Attendance marks, and the rules used to score them.
  • The Amazon scorecard rows the dispatcher imported, and how weeks are blended together.
  • The write-up record: who is at which step, for which week, and the counted reasons behind it. Never the letter that was sent, and never the dispatcher's private note — those stay on the computer.
  • Fleet records. Vans, not people.
  • The associate list imported from the DSP's Amazon portal, with legal names, phone numbers and driver's licence details taken out at the source.
  • The pad board — sides, groups, letters and two times. The only one with no people in it at all.
• The driver portal list. For each of the DSP's current drivers, the same one-way hash and their first name and last initial ("Juan P."), so the portal knows who may sign in and can show this week's top 10. The server refuses any longer form of a name. A driver who leaves the DSP's list drops off it, and with it loses access. Plus, while a driver is signed in, the SHA-256 of that phone's session. See The driver portal below.

What this server never receives

• Driver full names, emails, phone numbers or Transporter IDs from Amazon. They are replaced at the source. Apart from the first name and last initial kept for the driver portal, the server cannot tell who a given identifier belongs to; only the dispatcher's browser can. The names of the DSP's Sling users do cross it, unstored, on their way to the browser: see Reconciling with Sling. A driver's email crosses it, unstored, when that driver signs in to the portal.
• Any Amazon credential. Loadout reads Amazon inside the dispatcher's own logged-in session. It never stores, proxies or transmits a password or a session cookie.
• Damage photos. They stay on the computer that took them.
• The conversation with the assistant. It is kept in the browser. This server passes each question through and keeps no copy of it. The assistant itself keeps a thread — see below.

The assistant

Questions are relayed to a language model to be answered. Because the context is pseudonymised before it leaves the browser, the model sees P07, not a person. Answers come back with the same identifiers and the extension puts the names back on screen, locally.

So it can follow a conversation from one question to the next, the assistant keeps a thread, held under an identifier derived from the licence — never from a person. That thread is the one thing tied to a DSP that lives outside the database described above, which also means that deleting the database does not remove it. It is removed separately, on the same request. We would rather write that here than leave it for someone to find.

Reconciling with Sling

To compare the Amazon week with the Sling schedule and propose fixes, the browser sends the week with every person already replaced by a one-way code. This server adds the DSP's Sling sign-in, for that request only, and passes both to Loadout's reconciliation engine, on a server we run. The engine reads the schedule through Sling's official API, replaces each Sling email with the same kind of code, and answers with what doesn't match. It stores none of it, and its log records failures only. It cannot write to Amazon: it never receives the identifiers a change in Amazon needs, so every change there is made by the dispatcher's browser after the dispatcher confirms it.

One exception, written here on purpose: so that someone who is in Sling but not on the Amazon roster shows up with a name, the engine answers with the names of the DSP's Sling users, their emails already replaced by the code. Those names cross this server on their way to the browser, and neither server keeps them.

The driver portal

Each DSP's drivers can open the driver portal on their own phone, at drivers.load.lat, and sign in with the email they use for Amazon. This server uses that email twice and keeps it neither time: to work out the same one-way hash the backup uses, so it can find that driver, and to send a six-digit code from Loadout's own email account. Someone whose email is not on any DSP's list gets the same answer and no email. Codes are stored only as a keyed hash, work once and expire after 10 minutes; a session lasts 30 days on a phone where the driver chose to stay signed in, 12 hours otherwise, and ends when the driver signs out or leaves the DSP's list.

Signed in, a driver sees their own record, worked out from the backup with the same rules the dispatcher's screen uses: their company score, their attendance week by week and overall, their Amazon scorecard week by week with where the points went, and any van incident that took points off. Nothing about the DSP itself is shown. Of other drivers they see only this week's top 10 — first name, last initial, rank, Amazon score, standing and packages delivered that week, which break ties — and never anyone else's attendance, metrics or incidents. It is read-only: nothing a driver does in the portal changes the DSP's records, and the portal never contacts Amazon.

Other services, and what leaves the browser for them

• Email and text messages for signing in. The owner's two sign-in codes, and a driver's portal code, are sent from Loadout's own accounts: email through Cloudflare, text messages through Twilio. They carry a six-digit code and the DSP's name, nothing else. The owner's mobile number is used only for this: one message each time the owner asks for a code, never marketing. Message and data rates may apply; reply STOP to opt out or HELP for help. Mobile numbers and text-message consent are not shared with third parties or affiliates for marketing or promotional purposes. SMS terms: /terms.
• Sling. Loadout uses the DSP's own Sling account through Sling's official API. The DSP connects it once, in Settings: Connect Sling asks Chrome for access to app.getsling.com and, after that click, reads once the sign-in token that the DSP's own signed-in Sling tab already keeps; it can also be pasted by hand. This server stores it encrypted and renews it before it expires, so nobody has to reconnect every four weeks. It is never shown back — not even to the DSP, who can only see whether it works. Loadout reads the schedule, and writes a shift only after the dispatcher confirms that exact shift.
• Email and Twilio, for write-ups. An email write-up opens as a draft in the dispatcher's own mail — Gmail or their mail app — and the dispatcher presses send. A text goes out through the DSP's own Twilio account, straight from the browser, after the dispatcher confirms it. Neither passes through this server: the letter carries the driver's name, email or phone, and this server is built not to see those. One click, one confirmation, one message — nothing is sent in bulk and nothing is sent on its own.
• Mapbox, for road distances. Through Loadout's own Mapbox account, which makes Mapbox a processor of ours. To measure how far a route is by road, the browser sends Mapbox bare coordinates: the station, the center and first stop of each route, the stops of a route being measured, a driver who has finished alongside the ones who need help, and an electric van whose way back to the station is being checked. No name, no identifier and no written address goes with them.
• Demo licences. A demo licence works against a simulated logistics portal and schedule service that we run, at sandbox-portal.load.lat and sandbox-sling.load.lat, with made-up data and no real person in it. Other licences never ask for access to them.

Amazon

Loadout reads and writes only inside the DSP's own authenticated session, with the DSP's consent, and every write is confirmed by the dispatcher first — nothing is sent to Amazon automatically. The extension does not attempt to disguise itself or evade detection of any kind.

The associate list. When it syncs, Loadout reads the DSP's own associate list from Amazon's DA Console, inside the same session: names, work emails, Transporter IDs, status, qualifications and licence expiry, to show the roster and the Employees list, and each driver's mobile number — the personal one, or the work one if there is no other — so that a dispatcher can text a write-up. The mobile numbers are taken out of the list before it leaves that page and kept apart, on that computer only: they are not backed up, never sent to this server, and used only when the dispatcher presses Send text. A number the dispatcher types in Loadout takes the place of Amazon's.

Live routes listens to the DSP's own Amazon operations page while the computer has an active licence: the extension keeps a copy of what that page already loads — route progress, the plan, shift times and each driver's last reported position, plus the stops of a route the dispatcher opens there — so it can show which routes are at risk. It makes no requests of its own, and it opens, navigates or clicks nothing on that page: routes and stops are opened by the dispatcher. Drivers' names, initials and phone numbers, customers' names, phone numbers and streets, door codes and delivery notes are dropped as the data arrives; a customer's address is reduced to a map point, and a package's ID to a code. That copy stays in the browser's session memory: it is not backed up, not sent to this server, and is cleared when the browser closes or the licence stops being active. Only the bare coordinates described under Mapbox ever leave it.

Rivian FleetOS

Loadout reads Rivian FleetOS while the computer has an active licence, with the access to rivian.com that Chrome grants when the extension is installed: once a minute it copies five columns of the vehicle list that the DSP's own FleetOS tab already shows — VIN, distance to empty, charging status, state of charge and mileage — to know each electric van's battery. It sends Rivian no requests, clicks nothing and reads no cookies. The latest reading of each van is kept on that computer, next to its fleet records; it is not backed up, and removing Loadout's access to rivian.com in Chrome stops it.

Dispatch: what runs on its own, and what doesn't

Since version 0.74.0 (October 5, 2026) Dispatch has no switches: it works the same way on every computer with an active licence. Nothing runs with the browser closed.

• On its own. While the DSP's own Amazon operations page is open, Loadout keeps a copy of what it loads, each time that page refreshes itself (about every 30 seconds); while the DSP's own FleetOS tab is open, it copies the vehicle list that tab shows, once a minute. During a shift that a dispatcher starts with Start monitoring, and while the Loadout cockpit is open, it updates Live routes with every new copy and alerts the dispatcher when a route falls behind, is far from the station, or has a driver who finished and can help another route. It stops following a route when its driver signs out, and the shift ends on its own when every route is done and its driver has signed out (waiting at most three hours after the last route), or after 16 hours. When the driver of an electric van signs out, it checks a few minutes later (five, by default) that the van was left charging, and it checks whether a van still on the road can make it back to the station with a margin (10 miles, by default). Road distances are measured through Mapbox, as described above. None of this sends a request to Amazon or to Rivian.
• Only when the dispatcher does it. Opening a route or a stop in Amazon's operations page: Loadout offers a normal link that opens in the dispatcher's own tab, and Rescue planner says which stop to open next. Every change to Amazon or Sling, after the dispatcher confirms that exact change. Every write-up that is sent.
• Removed in 0.74.0. Two optional helpers, off by default, that acted in Amazon's operations page for the dispatcher: one opened far routes in a small Loadout window to measure them, the other expanded the stops of the route chosen for a rescue. Both are gone, with their switches. So are the switches for listening to the operations page and for reading FleetOS (both now follow the licence), the monitoring interval (it follows the page's own refresh) and the manual end time of a shift (it ends with the last sign-out).

Keeping and deleting

Usage counts are kept for 12 months. The backup is kept while the licence is active.

On the dispatcher's computer, someone who leaves both Amazon's associate list and Sling stays in Employees, with the date they left, for the one, two, three or five years the DSP chooses (three by default); then they are forgotten on their own, mobile number included. The DSP can also forget someone sooner, from their profile.

A DSP can ask for everything tied to its licence to be deleted — the backup, the usage counts, the list of computers, the owner's account, the stored settings, the Sling sign-in, the driver portal list and its sessions, and the licence record itself — and it is removed. What remains is one line in our own admin record: that it was deleted, when, by whom at Loadout and for which company, without the owner's email or mobile. The procedure is written down, step by step, so that the request is answered the same day instead of improvised, and so that anyone can check it was done. The assistant's thread, described above, is removed in the same pass.

Contact

Questions about this policy, or a request to delete a DSP's data: dspagentus@gmail.com.

Loadout · Last updated 2026-10-05