Privacy Policy

Last updated: 2026-10-04

This Privacy Policy describes how Needle Apps Inc. ("we," "us," or "our") collects, uses, stores, and shares information through our Transportation Management System ("GoTMS", the "Service"), including when the Service integrates with third-party telematics and Electronic Logging Device (ELD) providers such as Motive, Geotab, and Samsara, and with business applications a Customer chooses to connect, such as Dropbox, QuickBooks Online, and a company email mailbox.

This policy is intended for our customers (motor carriers and fleet operators), their drivers, and third-party integration partners evaluating a connection to our platform.

1. Who We Are

Needle Apps Inc. operates GoTMS, a Transportation Management System used by motor carriers to manage loads, dispatch, drivers, equipment, compliance, and billing. Our customers are companies ("Customers"); the individuals who use the Service on a Customer's behalf (dispatchers, drivers, administrators) are "Users."

Our [Terms of Service](/terms-of-service) govern a Customer's subscription, and our [End User Licence Agreement](/eula) governs an individual User's use of the web and mobile applications.

Contact: [email protected]

2. Information We Collect

2.1 Account and User Data

Name, email address, phone number, and hashed password for all platform users. Where an administrator connects QuickBooks Online, we also receive the email address of the Intuit account used to authorise that connection, for the confirmation step described in Section 5.2.

2.2 Driver Data

Where a Customer manages drivers through the Service, we process:

Identity and contact details: name, date of birth, address, phone, email
License and compliance data: license number, class, state, expiration, endorsements/restrictions, medical examiner information, MVR (motor vehicle record) results, drug and alcohol test records, FMCSA Clearinghouse query results
Hours-of-Service (HOS) logs and duty-status history
Emergency contacts and employment history
Owner-operator settlement banking details (collected only for owner-operator drivers, not company drivers): bank account holder name, institution name, account number, and routing/transit/institution numbers, recorded for reference in driver settlement records. This data is not transmitted to any bank or payment processor by the Service.
Device information from the driver mobile app (platform/OS metadata)

2.3 Location and Telematics Data

When a Customer connects a supported ELD/telematics provider (Motive, Geotab, or Samsara), we receive and store:

Vehicle location (latitude/longitude), speed, heading, ignition state, and odometer/engine-hour readings
Driver duty-status and HOS data reported by the ELD
Safety events (e.g., harsh braking, speeding) including associated video clip references, where the provider and Customer configuration support this
Fuel transaction records
Vehicle and driver roster information used to match records between systems (e.g., VIN, license plate, provider-assigned driver/vehicle IDs)

This data is received via provider webhooks (push) or scheduled polling, depending on the provider's supported integration method, and is used solely to power the Customer's own fleet visibility, compliance, and dispatch workflows within the Service. Raw vehicle location pings are automatically deleted after 365 days; duty-status/HOS, safety event, and fuel records are retained per Section 6.

2.4 Financial and Billing Data

Invoice, bill, and payment records between Customers and their customers/carriers/vendors. Card payment processing is handled by Stripe; we do not store full payment card numbers.

2.5 System and Audit Data

IP addresses and action logs are recorded in audit trails for security, compliance, and troubleshooting purposes.

2.6 Product Analytics and Session Replay

We use a session replay tool to diagnose faults and understand how the Service is used. It records a sampled subset of sessions: page navigation, clicks, and errors. It runs in a privacy-preserving mode in which text inputs are masked and email addresses are obscured before anything leaves the browser, and it is disabled entirely on public shipment tracking pages. We do not use this data for advertising or sell it.

3. How We Use Information

We use the information described above to:

Provide core TMS functionality (dispatch, load management, driver and equipment records, billing)
Synchronize vehicle/driver location and status from connected telematics providers into the Customer's dashboard
Support regulatory compliance (HOS, MVR, drug/alcohol testing records required under FMCSA and similar regimes)
Process driver settlement payments
Secure the platform (authentication, audit logging, fraud/abuse prevention)
Provide customer support and respond to inquiries

We do not sell personal information, and we do not use driver or location data for advertising.

4.1 What We Send

To establish and maintain an integration, we send connection credentials (API keys or OAuth tokens, stored encrypted at rest) to the provider, and identifiers needed to bind our internal driver/equipment records to the provider's driver/vehicle IDs. We do not push Customer operational data (loads, rates, customer/vendor records) to telematics providers.

4.2 What We Receive

As described in Section 2.3, we receive location, HOS, safety event, fuel, and roster data from the connected provider, scoped to the vehicles and drivers the Customer has authorized for that connection.

4.3 Other Third Parties

We use subprocessors for specific functions, including:

Cloud hosting and infrastructure providers
Managed database hosting
Object storage for documents and media (S3-compatible storage)
Stripe for payment processing
Email and messaging providers for transactional messages
An artificial intelligence provider for document field extraction (Section 5.5), which never receives data obtained from Google APIs
Application monitoring and session replay providers (Section 2.6)
Address autocomplete providers (Section 5.6)

The integrations in Section 5 are not subprocessors: they are the Customer's own third-party accounts, connected at the Customer's direction, and the Customer's relationship with those providers is governed by the provider's own terms.

Each subprocessor is bound by contractual confidentiality and data protection obligations. We do not share personal data with third parties for their own independent marketing purposes.

5. Business Application Integrations

A Customer may connect the integrations below. Each is optional, is enabled by a Customer administrator, and can be disconnected at any time from the Service's integration settings. Disconnecting deletes the stored credentials from the Service, so we can no longer reach the connected account. For a Gmail mailbox we also revoke the authorisation with Google (Section 5.3). For the other integrations, a Customer who wants the authorisation withdrawn at the provider as well can do so from that provider's own account settings.

5.1 Dropbox (Document Mirroring)

Where a Customer connects Dropbox, we upload a copy of documents uploaded to the Service into that Customer's own Dropbox account, so the Customer retains an independent copy of its operating paperwork.

What we send: the document file itself, and a folder path derived from the record it belongs to (for example a load number, driver name, or equipment unit number). Documents may include driver licences, medical certificates, bills of lading, proofs of delivery, and insurance certificates, so personal data can be included.
Access we request: the `files.content.write` permission, scoped to a Dropbox App folder. Dropbox confines us to a single folder it creates for the Service. We cannot read, list, modify, or delete anything else in the Customer's Dropbox, and we do not read back the files we write.
Deletion: deleting a document in the Service does not delete the copy in the Customer's Dropbox. That copy belongs to the Customer, in the Customer's own account, and we deliberately do not reach into it. A Customer or individual who wants a document removed from both places must delete it in the Service and in their Dropbox.
Credentials: the Dropbox access and refresh tokens are encrypted at rest.

5.2 QuickBooks Online (Accounting)

Where a Customer connects QuickBooks Online, we synchronise accounting records between the Service and the Customer's QuickBooks company file.

What we send: customer and vendor records (business name, contact name, email, phone, billing address), invoices, bills, and payment records, including line items and amounts.
What we receive: the corresponding records and their QuickBooks identifiers, so the two systems stay matched, along with sync status and error detail.
Access we request: the `com.intuit.quickbooks.accounting` permission, which covers the accounting records described above, together with the `openid` and `email` permissions. Those two return the email address of the Intuit account that authorised the connection, and nothing else. We use it once, on the confirmation screen shown to the authorising administrator, so they can see which Intuit account they signed in with and which QuickBooks company it reaches before any records are linked. It is discarded when the connection is confirmed or abandoned, and is not stored against the connected account. We do not request the `profile`, `phone`, or `address` permissions, so we never receive an Intuit account holder's name, telephone number, or postal address.
What we do not send: driver personal data, licence or medical records, hours-of-service data, and vehicle location data are never sent to QuickBooks.
Credentials: the QuickBooks OAuth tokens and company realm identifier are encrypted at rest.

5.3 Email (Gmail, Microsoft 365, and SMTP providers)

A Customer may connect a company mailbox so that load confirmations, invoices, and similar documents are sent from the Customer's own address rather than a generic one.

What we send: the message we are asked to send — recipients, subject, body, and any attachments the User selected.
Access we request: permission to send mail, together with the minimum identity access needed to record which mailbox is connected and to keep the connection alive without asking a User to sign in again — `gmail.send` and `userinfo.email` for Gmail, and `Mail.Send`, `User.Read` and `offline_access` for Microsoft 365. We do not request, and cannot exercise, the ability to read, search, label, or delete messages in a connected mailbox.
What we receive from Google: the email address of the connected Google account and the OAuth tokens that let the Service send on its behalf. Gmail's reply to a send carries only a message identifier. We never receive the contents of the mailbox.
Records: we retain a record of messages the Service sent, including recipients and content, so a Customer can audit what left its account.
Disconnecting Gmail: when a Customer disconnects a Gmail mailbox, we revoke the Service's authorisation with Google and delete the stored tokens and connected address. If Google cannot be reached at that moment, the tokens are still deleted from the Service, and the authorisation can be removed from the Google Account's security settings.
Drafts: for Gmail, "Open in mail app" downloads the message as a file to the User's device; we do not create drafts in, or otherwise write to, a Gmail mailbox.
No artificial intelligence use of Google user data: data obtained through Google APIs, whether raw, aggregated, anonymised, or derived, is never sent to any artificial intelligence or machine learning provider, including the document extraction provider in Section 5.5, and is never used to create, train, or improve any artificial intelligence or machine learning model, whether ours or a third party's. We do not operate, host, or train our own models.
Google API Services Limited Use: our use of information received from Google APIs adheres to the [Google API Services User Data Policy](https://developers.google.com/terms/api-services-user-data-policy), including its Limited Use requirements. We use Gmail access solely to send messages a User composes or triggers in the Service. We do not transfer this data except as necessary to provide that feature, do not use it for advertising, do not allow humans to read it except with the User's explicit consent, for security purposes, or as required by law, and do not use it to train generalised artificial intelligence models.

5.4 Messaging (WhatsApp Business and SMS)

Where a Customer enables messaging, we send notifications to recipients the Customer specifies. We transmit the recipient's phone number and the message content to the messaging provider. Message delivery status is recorded against the Customer's account.

5.5 Automated Document Extraction

When a User asks the Service to extract fields from a document they uploaded to the Service, that document is transmitted to a third-party artificial intelligence provider (Anthropic, through its commercial API) for processing, and the extracted fields are returned to the Service. Documents submitted for extraction may contain personal data. The provider's commercial terms prohibit it from using submitted content to train its models. Extraction output is a draft and must be reviewed by a User before it is relied on.

Extraction only ever runs on files Users upload to the Service directly. It is never given data obtained through Google APIs or any connected mailbox (see Section 5.3), and no connected mailbox, Google or Microsoft, is read by the Service at all.

5.6 Address and Carrier Lookup

To help Users enter accurate data, the Service sends partial address text to an address autocomplete provider, and carrier identifiers (such as a DOT or MC number) to public regulator lookup services, including the US FMCSA and Canadian federal business registries. These requests carry the search term only; they do not carry driver, load, or financial data.

6. Data Retention

We retain data for as long as the Customer's account is active and as needed to comply with applicable legal, regulatory, and contractual retention requirements. For data sourced from telematics/ELD integrations, retention is driven by FMCSA recordkeeping rules for the underlying record type, including:

Hours-of-Service (HOS) / ELD records: minimum 6 months (49 CFR §395.8); the Service does not auto-delete this data
Driver qualification files (license, medical certification, MVR): duration of employment plus 3 years after separation (49 CFR §391.51); the Service enforces a minimum record age before an MVR record can be deleted
Drug and alcohol testing records: minimum 5 years (49 CFR §382.401); the Service blocks deletion of a record until this minimum has elapsed
FMCSA Clearinghouse query results: minimum 3 years (49 CFR §382.401); the Service blocks deletion of a record until this minimum has elapsed
Vehicle inspection and maintenance records: 1 year, or 6 months after a vehicle leaves the fleet (49 CFR §396.3)
Raw vehicle/driver location pings: automatically deleted after 365 days

Customers may request deletion of their data subject to these minimum retention obligations.

7. Security and Data Protection

We protect personal and sensitive data, including data obtained through Google APIs, with the following mechanisms:

Encryption in transit: all traffic between browsers or mobile apps and the Service, and between the Service and integrated providers (including Google's APIs), is encrypted with TLS (HTTPS).
Encryption of credentials at rest: OAuth access and refresh tokens for connected mailboxes (Gmail, Microsoft 365) are encrypted with AES-256-GCM before they are stored, using a key held outside the database. Other integration credentials (telematics, accounting, and storage providers) are also encrypted at rest.
Passwords: stored using salted hashing (bcrypt); we never store plaintext passwords.
Authentication: industry-standard token-based sessions (JWT) with refresh-token rotation, with optional two-factor authentication.
Least-privilege access to Google data: we request only the Gmail permissions needed to send mail and identify the connected address (Section 5.3). The Service cannot read, search, or delete mailbox content.
Access control: access to Customer data, including the connected mailbox and the record of sent messages, is restricted by role-based permissions within the Service, and each Customer's data is isolated from every other Customer's. Our personnel do not view Google user data except with the User's explicit consent, for security purposes, or as required by law.
Audit logging: security-relevant actions, including connecting or disconnecting a mailbox and every message sent, are recorded in audit trails.
Deletion and revocation: disconnecting a mailbox deletes its stored tokens and connected address from the Service immediately, and for Gmail also revokes the Service's authorisation with Google. A User can also revoke the Service's access at any time from their Google Account's security settings.
Sensitive data handling: sensitive data is used only to provide the feature it was collected for, is never sold, and is never used for advertising.

8. Data Location

Application infrastructure and databases are currently hosted in North America (Canada and the United States). As we grow, we may add infrastructure in additional regions to support customers closer to their operating area; this policy will be updated to reflect any such change. Object storage and payment processing may involve subprocessors located in other regions, each under appropriate data protection safeguards.

9. Data Subject Rights

We operate in North America and are not subject to the EU General Data Protection Regulation (GDPR). Depending on applicable US state law (e.g., the California Consumer Privacy Act, as amended by the CPRA, for California residents), individuals may have the right to access, correct, or request deletion of their personal data, or to opt out of certain data sharing. We do not sell personal information. Requests should be directed to the relevant Customer (who determines the purposes and means of processing for their own drivers and users) or to us at [email protected], and we will route the request appropriately.

[email protected]