Everlance trip logs and synced expenses, on a feed you control

The export problem

Everlance's own data export expires seven days after you generate it, and the bank-synced side of it reaches back only about three months, per the company's help documentation. That is fine for a driver pulling a tax report once a year. It is the wrong shape for a finance team, a reimbursement platform, or a tax product that needs the same mileage and expense records on a steady feed. The records exist and they are clean — automatic GPS trips, swipe-classified work miles, Plaid-linked card transactions with receipts. The job is getting them out on a schedule you own instead of an emailed link that dies in a week.

This brief maps what Everlance holds, the authorized way we reach it for the account holder, and the runnable code we hand back. It is written for whoever has to consume Everlance data downstream, not for a casual user.

Data Everlance holds

Each row below is a surface the app actually renders to an account holder, named the way Everlance names it. Granularity is what an integrator can expect per record.

Routes in

Three routes genuinely apply here. None of them requires anything from you up front beyond the app name and what you want out of it; the account access is arranged with the account holder during onboarding.

1 · Scheduled Data Export, driven for the account holder

The Web Dashboard generates a mileage report and a transaction report over a chosen date range, purpose and business line. We drive that flow on a schedule against the account holder's consented session and normalize each report before its seven-day life runs out. Effort is low to moderate. Durability is high — the export is a stable product surface that rarely changes shape.

2 · Authorized interface integration of the dashboard

The export format drops things the dashboard itself shows: raw start and end coordinates per trip, the rule that auto-classified a trip, the receipt image attached to a transaction. We read those directly from the authenticated dashboard under the same consent. Effort is moderate. The front end can shift, so a change detector ships with the handover so a layout change surfaces as an alert, not silent data loss.

3 · Protocol analysis of the mobile client

The Everlance app talks to its own backend over HTTPS. Documented analysis of that authenticated traffic, again under the account holder's authorization, recovers the same trip and transaction objects the app renders, which is useful when you want the live mobile view rather than the dashboard's. Effort is higher; durability tracks the app's release cadence.

For most buyers the practical build is route 1 as the backbone, with route 2 filling the per-trip geometry and rule metadata the report leaves out. That pairing gives normalized history plus the detail the flat export discards, and it leans on the surface least likely to break.

What lands in your repo

Everything is scoped to Everlance's real surfaces, not a generic template.

• An OpenAPI specification describing a clean read interface over trips, classifications, transactions and team reports — the shape your services consume, decoupled from how Everlance renders it.
• A protocol and auth-flow report: how the consented dashboard session is established and refreshed, how the export job is queued and collected, and where Plaid sits between Everlance and the financial institution.
• Runnable source in Python or Node.js for the core pulls — generate-and-collect the mileage report, generate-and-collect the transaction report, and the dashboard read that recovers per-trip coordinates and rule metadata.
• Automated tests covering the report-not-ready retry, the seven-day expiry guard, and the team classification state so private trips never leak into a work feed.
• Interface documentation plus data-retention and consent guidance written against the CCPA and CPRA position on precise location.

Pull sketch

Illustrative shape of the export-collection path; exact field names and the job lifecycle are confirmed against a consenting account during the build.

# Authorized run for the account holder's own Everlance data.
# session carries the consented dashboard auth (cookie/token), not stored credentials.

def collect_mileage(session, start, end, purpose="work"):
    job = session.post("/data-exports/new", json={
        "type": "trips",
        "format": "csv",
        "start_date": start,        # ISO 8601
        "end_date": end,
        "purpose": purpose,         # work | personal | 
    }).json()

    report = poll(session, job["export_id"], timeout_s=180)
    if report["status"] != "ready":
        raise ExportPending(job["export_id"])      # retry on next cadence tick

    # Reports expire ~7 days after generation — fetch well inside that window.
    rows = fetch_and_parse(session, report["download_url"])
    return [normalize_trip(r) for r in rows]       # -> {trip_id, start_ts, end_ts,
                                                   #     miles, classification, line}

def normalize_trip(r):
    # The CSV omits raw coordinates and the auto-classify rule;
    # join from the dashboard trip view when route 2 is in scope.
    return {
        "trip_id":        r["Trip ID"],
        "start_ts":       to_utc(r["Start Date"], r["Start Time"]),
        "end_ts":         to_utc(r["End Date"],   r["End Time"]),
        "miles":          float(r["Distance"]),
        "classification": r["Purpose"],            # private/personal rows filtered upstream
        "line":           r.get("Business Line"),
    }
      

Freshness & cadence

Two timing facts shape the poller. The Plaid-backed transaction sync surfaces roughly the last three months, and a generated report expires after about seven days — both per Everlance's help center. We set the export cadence so transactions are captured and checkpointed before they roll off the rolling window, and so every report is collected and normalized inside its life. There is also email-delivery latency between requesting a report and it being ready; the run treats a not-ready report as a retry on the next tick, not a failure, so a slow generation never drops a period.

Location data and California privacy rules

Everlance's privacy policy states the app receives precise location from the device GPS while it runs, when location permission is granted. Under the California Consumer Privacy Act as amended by the California Privacy Rights Act, precise geolocation is sensitive personal information, and a consumer can direct that it be used only for the service they asked for. The integration is built to match that: it moves the account holder's own records under their consent, minimizes to the fields the downstream use actually needs, and supports deletion and use-limitation requests rather than hoarding raw GPS. Where Everlance Business is involved, an NDA covers the engagement. (California has a proposed location-privacy bill that would require affirmative opt-in consent; it has not been enacted, so we build to the current CCPA and CPRA position and note the proposal as a forward risk, not a present obligation.)

What we plan around

These are concrete things this app does that the build accounts for.

• The "Work" label is not constant. For a team member it becomes the company's own work purpose, usually the company name, while self-employed users see Work / Personal / Other. We map that per account so a single ingest treats both correctly.
• Unclassified and personal trips and transactions stay private to the member and never appear to the company. We model that classification state machine so a team feed pulls only what a member has classified and submitted — matching the admin portal, not over-reading.
• The bank sync is a rolling roughly-three-month window. We checkpoint and accumulate so older transactions are retained in your store after they leave Everlance's view.
• Export capability differs by plan: the free tier yields a CSV of trips and transactions, while Starter and Professional add format and filter options. We detect the tier and adapt the extraction path instead of assuming one.

Where teams use it

• A reimbursement platform pulling each driver's approved work miles per pay period and paying at the configured rate, with personal trips excluded by construction.
• A tax-prep product back-filling a year of IRS-style mileage and categorized expenses without the client re-generating expiring exports by hand.
• A field-operations finance team reconciling Plaid-synced card spend against trip activity, joined on member and date.

Apps in the same space

Buyers integrating Everlance often hold data in neighbouring tools too; a unified feed usually has to span several of them. Named here for ecosystem context, not ranked.

• MileIQ — automatic drive detection with swipe classification; per-trip mileage records behind an account.
• Stride — free mileage and expense tracking with manual start-stop trips and deduction estimates.
• TripLog — GPS mileage with multi-vehicle support and accounting-platform connections.
• Gridwise — gig-driver mileage plus earnings pulled from delivery and rideshare platform links.
• Hurdlr — real-time income, expense and tax tracking with bank, Uber, Square and Stripe links.
• QuickBooks Self-Employed — mileage tracking inside a broader self-employed bookkeeping ledger.
• SherpaShare — background GPS trip logging with driver analytics and demand heat maps.
• Driversnote — automatic logging with IRS and per-country compliant mileage reports.
• Timeero — time tracking with GPS location and mileage for mobile workforces.

Integrator questions

Does the export carry per-trip GPS coordinates, or only total distance?

The emailed CSV or Excel report carries per-trip distance, timestamps, classification and business line, but the raw start and end GPS points and the Favorite-Trip and Work-Hours rule metadata live in the dashboard trip view. We pull both surfaces and join them so the feed keeps the route geometry the report drops.

How do you keep more than three months of card history when the bank sync only holds a rolling window?

Per Everlance's help documentation the Plaid-backed transaction sync surfaces roughly the last three months. We checkpoint each pull and accumulate transactions in your own store, so history past that window is retained instead of lost when it rolls off.

For an Everlance Business team, what does the feed actually see?

Trips and transactions a member leaves unclassified or marks personal stay private to that member. The Team Dashboard exposes approved, work-classified mileage and submitted expenses per pay period. We model that classification state so a team feed ingests only what has been classified and submitted, matching what the admin portal shows.

Which California privacy rules apply, given the app records precise location?

Everlance's privacy policy states it collects precise GPS location while the app runs with location permission granted. Under the CCPA as amended by the CPRA, that precise geolocation is treated as sensitive personal information, so the integration is built around the account holder's consent, data minimization and the right to limit use to the requested service.

Can you drive the Data Export on a schedule even though the download link expires?

Yes. Per Everlance's help center, generated reports expire after seven days, so the build fetches and normalizes each mileage and transaction report well inside that window rather than depending on a link that dies.

What we checked

Reviewed in May 2026 against Everlance's own help center and privacy policy plus the California Attorney General's CCPA page: the Data Export flow and its seven-day expiry, the Plaid bank-integration behaviour and its roughly-three-month sync window, trip classification semantics for individuals and teams, and the precise-location disclosure. Primary sources:

• Everlance — How to Generate a Data Export
• Everlance — Expense Tracking via Bank Integration (Plaid)
• Everlance — How to Classify Your Trips
• California Attorney General — CCPA

OpenBanking Studio integration desk · mapping reviewed May 2026.

Source for the trip-and-transaction pull lands in your repository in one to two weeks. Take it as a one-off delivery from $300, billed only after it is running and you are satisfied, or call our hosted endpoints and pay per call with nothing committed up front — either way you give us the app name and what you need from its data, and we arrange the consented access with the account holder. Start the conversation at /contact.html.