Pulling MyXpense entries out of the ExpenseCount web companion

ExpenseCount Inc. publishes three sibling ledger apps that share the same back end at expensecount.com — MyXpense for one-person income and expense tracking, MessXpense for shared-housing meal and bill splitting, and WeXpense for trip-style group expenses. The developer's own home page cites roughly 500K users and 10M+ entries across the family. For an integrator the practical question is not really "where is the data" — it lands on expensecount.com — but how to reach a single user's slice of it, on what cadence, and how to keep the no-credentials mode from quietly losing track of which device owns which ledger.

Where the entries live

The mobile app holds a working copy and ships it to the web companion when there is connectivity. The web companion is what holds history that a third party can pull against. Subscription state is separate — it sits in Apple's in-app purchase system (the iOS listing shows a $2.19 monthly tier and a $9.99 six-month tier) and is not part of the ledger an integrator cares about.

How we reach them

Authorized interface integration against the web companion

The web companion at expensecount.com is the route we recommend. We work with the consenting user, log in once on their behalf in a contained environment, and document the request/response shape of the per-user log page so the integration can hold a session and poll page-by-page from a cursor. This is what the rest of this brief assumes. Effort sits in mapping the page response to a clean schema; durability is good — the surface is the one the developer themselves point users at for log history.

User-consented session access

For one-shot pulls (e.g. a year-end export into accounting), we can drive the same web companion as a logged-in user under a short consent window, dump the period, and unwind. Cheap to stand up, no infrastructure to keep alive.

Native export from the app

The developer advertises "pdf, webpage, anything" export. We treat this as a fallback only — it works for a single hand-off but not for a continuous feed.

The recommended spine is the first route, with the second as the cheaper option when a customer only needs a one-time pull. We size the build assuming the first.

An ingest call, sketched

The web companion serves a per-user log page; the integration walks it from newest to oldest and stops at the previous cursor. Endpoint paths below are illustrative — exact paths and field names are confirmed during the build against the consenting user's account.

# Pull entries newer than the last known cursor from the ExpenseCount web log.
# Built around the consenting user's session, established in the auth-flow report.

import httpx
from typing import Iterable

class ExpenseCountSession:
    def __init__(self, cookies: dict[str, str]):
        self.client = httpx.Client(
            base_url="https://www.expensecount.com",
            cookies=cookies,
            headers={"User-Agent": "OFL-Integration/1.0"},
            timeout=httpx.Timeout(20.0),
        )

    def entries_since(self, cursor_ts: str) -> Iterable[dict]:
        page = 1
        while True:
            r = self.client.get("/Expense/log", params={"page": page})
            r.raise_for_status()
            rows = parse_log_page(r.text)  # html parser shipped with the build
            if not rows:
                return
            for row in rows:
                if row["ts"] <= cursor_ts:
                    return
                yield row
            page += 1

def parse_log_page(html: str) -> list[dict]:
    # Returns a list of dicts: {"entry_id", "ts", "kind", "amount",
    # "currency", "category", "note"}. The parser is the part that is
    # confirmed against the live response shape during the build.
    ...

A normalized entry, roughly

The shape we hand back, after the parser pass, is the same regardless of which sibling app produced the entry. This keeps the personal book (MyXpense), the shared-housing book (MessXpense) and the trip book (WeXpense) interoperable when the consenting user has more than one.

{
  "entry_id": "ec-2026-05-27-personal-0001",
  "ts": "2026-05-27T14:22:10Z",
  "kind": "expense",
  "amount": { "value": "12.40", "currency": "USD" },
  "category": "Groceries",
  "note": "Trader Joe's",
  "book": { "app": "MyXpense", "scope": "personal" },
  "ingested_at": "2026-05-27T14:25:01Z"
}

What you get from us

Deliverables are sized for an ingest-shaped engagement — runnable code first, paper second.

• A Python client library (httpx-based) that holds the consenting user's session, walks the web log, applies the parser, and emits normalized entries — the same code in the snippet above, fleshed out, with retry and backoff.
• A Node.js port of the same client where the destination stack is JavaScript, sharing the parser test fixtures so behaviour stays identical.
• A webhook-style emitter — your endpoint receives one POST per new entry, signed with an HMAC you set, idempotent on entry_id, so the pipeline is the same shape whether the back end is a queue, a spreadsheet sink, or an accounting API.
• An automated test suite that replays a captured corpus of log pages through the parser, plus a small end-to-end smoke test against a sandbox account the build is run under.
• An OpenAPI document and a short auth-flow report covering the cookie/session chain and the rebind behaviour when the consenting user signs in on a new device.
• Interface documentation and a data-retention note for the ingestion side — how long entries are kept, what is logged, what is purged on consent revocation.

Things this build has to handle

These are the parts that turn this from a scrape into something a customer can actually run on a Tuesday morning without paging anyone.

• Three apps, one back end. ExpenseCount Inc.'s personal, mess and group apps appear to share an account fabric. The integration is scoped to the personal book by default and we agree in writing whether the consenting user wants the mess and group books pulled into the same feed; if yes, the schema's book.scope field carries the distinction and the destination can route on it.
• The no-credentials mode. The listings advertise that MyXpense can be used without username and password, so identity is sometimes pinned to a device. We treat the web-side session of a consenting user as the durable hook — the build runs against an account where that user has signed in on the web, and we document the rebind procedure for when they re-authenticate on a new phone.
• Offline-then-sync semantics. The mobile app works offline and ships entries when it next has connectivity, so the integration's "now" is whenever the device last sync'd, not wall-clock. Cursoring is by ledger timestamp on the entry, not by ingest timestamp, and we make this visible in the test suite so freshness is measured honestly.
• Category is free text. We ship a per-account category map and a small UI to maintain it, rather than guessing a one-size-fits-all chart of accounts; the consenting user (or your operator) reviews unmapped labels.
• Subscription state is off-page. Apple manages the IAP tier; we keep it out of the ledger pipeline so a lapsed subscription does not silently shape the data.

Privacy and consent

The Apple privacy card for MyXpense lists user ID and email as data linked to the user, with crash and performance telemetry not linked. There is no banking or open-finance regulator in scope here — the ledger is user-entered personal finance data, not aggregated bank data — so the relevant frame is general data-protection law: GDPR for users in the EU, the UK GDPR for the UK, CCPA/CPRA for California residents, and the equivalent local statute elsewhere. We operate under written authorization from the consenting user, run against either the user's own account or a sponsor sandbox arranged with them, log access for audit, minimise the data captured to what the customer actually asked for, and sign an NDA when the destination is sensitive. Consent is revocable; on revocation the pipeline stops and downstream cached entries are purged per the data-retention note shipped with the build.

Where these notes come from

What we checked: the MyXpense Play Store listing for the package id and feature claims; the iOS App Store listing for version, subscription tiers, and the privacy card; the developer's own home page for the sibling-app architecture and the user/entry counts they cite; and the WeXpense and MessXpense listings to confirm the shared back end.

• MyXpense on Google Play
• My Xpense on the App Store
• ExpenseCount developer home
• ExpenseCount Inc. developer page on the App Store

Reviewed 2026-05-27 by the OpenFinance Lab integration desk.

Sibling and similar apps

These are the apps that come up alongside MyXpense in the ledger-and-budgeting space. Where a customer asks for one feed, they often end up asking about a couple of these too; the architecture above generalises straightforwardly to the same shape.

• WeXpense — ExpenseCount Inc.'s sibling app for group trip and event splitting, on the same back end as MyXpense.
• MessXpense — ExpenseCount Inc.'s sibling app for shared-housing meal and bill tracking, also on the same back end.
• Monarch Money — bank-linked dashboard with a partner integration story rather than manual ledger entry; common companion when the customer wants both manual and aggregated views.
• Rocket Money — bank-linked categoriser, subscription tracker; same family of consolidation target as Monarch.
• PocketGuard — budgeting view layered on bank-linked feeds; popular as a downstream destination for cleaned-up ledger data.
• YNAB — envelope-style budgeting with its own data model; often the destination when manual ledger entries from MyXpense are forwarded into a budgeting workflow.
• Spendee — multi-source ledger with bank links and manual wallets; closest peer to MyXpense in shape and the most natural side-by-side migration story.
• Wallet by BudgetBakers — bank-linked plus manual entries on Android-first; another natural side-by-side or replacement target.
• My Expenses (Totschnig) — open-source Android expense tracker with QIF and CSV export; useful reference for what a self-hosted version of the same pipeline looks like.

Questions an integrator asks

Why ingest from the web companion rather than the mobile app itself?

The MyXpense apps work offline and then sync; the durable record an integrator can rely on is the per-user log on expensecount.com, where every entry eventually lands. Ingesting from the web side means the pipeline gets the same view a logged-in user would see, without depending on whichever phone last opened the app.

How does the build handle the "no login required" mode the listings advertise?

It treats the web-side signed-in session of the consenting user as the durable hook. The build runs against an account where the user has signed in on the web; we document the rebind procedure for when they next re-authenticate on a new device so the integration does not silently lose its anchor.

What does refresh cadence look like for a daily ledger of a few dozen entries?

For a single user adding a handful of entries a day, a poll every 5 to 15 minutes is plenty and is gentle on the web companion. For batch destinations (an end-of-day push to an accounting system), an hourly or end-of-day cursor walk is enough. The webhook emitter in the deliverable lets the destination receive entries as they are seen, regardless of the underlying poll interval.

Categories are free-text in the app — how do they end up as a chart of accounts?

The build ships a per-account category map, seeded from whatever labels the consenting user has actually used in their MyXpense history, and a thin UI to maintain it. Unmapped labels surface for review rather than being silently coerced; that keeps the bookkeeping side honest when a new category appears.

MyXpense ingest typically lands inside a one-to-two-week cycle once the consenting user's session is in hand. Source-code delivery from $300, paid after we hand it over and you have run it against your own account; or a pay-per-call hosted endpoint, billed only on queries with no upfront fee. Tell us the destination and we will scope it.