How RoverDrop works

Getting started

Create your firm's account. The person who creates it becomes the administrator. Add your team on the Settings page. There are three roles:

• Field submits packets and tracks them in My Submissions.
• Office does everything Field does, plus accepts, files, reassigns, and views reports.
• Admin does everything Office does, plus manages users, jobs, and settings.

There is no self-signup within a firm. Accounts are created by the administrator, so the user list stays under your control. If your firm uses Microsoft 365, users can sign in with their Microsoft account once it is configured; the email address must match an existing RoverDrop account.

Submitting a packet

The form has three fields: title, cover sheet, files. An optional job number tags the packet for filtering and routing. There is no recipient field and no folder to choose. Every packet goes to your firm's single intake queue.

• Files upload directly to storage in resumable pieces. A dropped connection resumes where it left off instead of starting over.
• A packet does not count as submitted until every file is fully uploaded and its size is verified server-side. A SHA-256 checksum is recorded for each file.
• The submitter gets a numbered receipt on screen and by email, and stays responsible for the packet until the office accepts it.
• With no connection at all, the packet is saved on the device and sent automatically when the signal returns.

Accepting and filing

The intake queue shows every packet with its status, submitter, and how long it has been waiting. Unaccepted packets sort to the top, oldest first, color-coded by age.

• Accept transfers responsibility to the acceptor, by name. Downloading files never transfers responsibility; it is logged but non-custodial.
• Mark filed records that the files were placed in their final destination. This is the done state that reports measure against.
• Reassign moves responsibility to another office user, who is notified by email.
• Both accept and filed can be undone, with an optional reason. Undo is recorded in the audit trail and the affected person is notified. History is never rewritten.

Supplements and comments

Packets are immutable after submit. To correct or add files, use Send a supplement on the packet page: it creates a new packet linked to the original in both directions.

Comments on a packet are emailed to everyone involved: the submitter, the current responsible person, the acceptor, and prior commenters. Comments live in the packet record instead of a reply-all thread.

Notifications

• New packet: the office group is emailed; the submitter gets a receipt.
• Aging reminders: packets unaccepted past a threshold (default 4 hours) trigger escalating emails until someone accepts. Thresholds are set on the Settings page.
• Daily digest: one email summarizing everything open.
• Routing rules: Admin can route a job number to a specific person, who gets a direct email when a matching packet arrives. Anyone can still accept.

Email intake

Each firm has a private intake address, shown on the Settings page. Email sent to it becomes a normal packet: subject is the title, body is the cover sheet, attachments are the files. Only mail from an active user's address is accepted. This is a bridge for crews who still work from their inbox; the receipt, custody, and archive behavior is identical.

Reports

The Reports page (office and admin) shows median time-to-accept and time-to-file, an aging breakdown of unaccepted packets, weekly submission volume, and the longest-waiting open packets, over 7 to 365 day periods.

API

Admins create read-only API tokens on the Settings page. The token is shown once. Use it as a bearer token:

curl -H "Authorization: Bearer rd_..." \
  "https://your-roverdrop-host/api/v1/packets?status=submitted&limit=50"

• GET /api/v1/packets lists packets. Filters: status (submitted, accepted, filed), since (ISO date), limit (max 500).
• GET /api/v1/packets/<id> returns one packet with its files (names, sizes, SHA-256 checksums) and full audit trail.

Tokens are scoped to your firm and can be revoked at any time.

Webhooks

Set a webhook URL and signing secret on the Settings page. RoverDrop POSTs JSON on every packet event: packet.submitted, packet.accepted, packet.unaccepted, packet.filed, packet.unfiled, packet.reassigned.

Each delivery includes an X-RoverDrop-Signature header: the hex HMAC-SHA256 of the raw request body using your signing secret. Verify it before trusting the payload:

const expected = crypto
  .createHmac("sha256", secret)
  .update(rawBody)
  .digest("hex");
const valid = expected === request.headers["x-roverdrop-signature"];

Security and storage

• File bytes go directly from the browser to object storage over TLS; they do not pass through the application server.
• Every file gets a SHA-256 checksum and a server-side size verification before the packet counts as submitted.
• As soon as a packet is submitted, every file is copied to write-once archive storage (locked against deletion and overwriting). Retention rules remove working copies later; the archive copy is always kept.
• Each firm's data is isolated: queries, files, and API tokens are scoped to the firm. Passwords are hashed with bcrypt. Sessions expire after 14 days idle.
• The audit trail is append-only. Undo actions add events; nothing is deleted or rewritten.

Questions not covered here: support@roverdrop.com