Getting income and expense records out of MyXpense

ExpenseCount Inc.'s MyXpense keeps every income line and every expense line in a small server-side log behind a per-install identifier — that log is what an integrator usually wants to reach. The app is described on its own listings as needing no username or password, working offline, and exposing the same record set through the Android client, the iOS client, and the expensecount.com web portal. Three surfaces, one log. The integration target is the log, not the UI.

Records actually held inside MyXpense

Six concrete surfaces are worth naming for anyone planning to sync against MyXpense. They map cleanly to the way the app talks about itself.

Routes into the data

Three routes apply here. They are not equivalent and we usually combine two of them.

Authorized interface integration with the ExpenseCount sync layer

The web portal at expensecount.com clearly reads the same log the mobile clients write to. We capture the request and response shapes against a consenting account that we set up with you, and we build the client off that capture. This route gives live entries, the category list, and the historical window the device has already synced.

The in-app export as a secondary input

The send-report feature, called out on the ExpenseCount product page, produces a PDF and a web report. When a user has been working offline for a long stretch, that export contains rows the cloud doesn't have yet. We parse it through a small reader so the client can present a single merged view rather than two partial ones.

User-consented on-device extraction

Where the use case truly cannot tolerate any sync gap — for example a one-time migration into a different finance tool — the local store on the user's own device can be exported with their explicit consent and parsed alongside the cloud pull. This is the route we use least, but it exists.

For most projects the sync-layer route does the heavy lifting and the report export is wired in behind it as a fallback, so offline-only entries do not silently disappear. That choice is made together with you, against the actual user behaviour you need to support.

Privacy posture for a no-login expense app

MyXpense is not bank-connected. It does not pull statements, it does not initiate payments, and there is no Open Banking regime that applies to it the way one would apply to a bank app. The relevant frame is general data protection — GDPR for users in the EU, and equivalent local rules elsewhere — applied to the user's own self-entered financial diary.

The practical consequences are short. The user is the data subject and the data controller of their own log. Our role on the integration is processor: we read on their authority, we keep an explicit consent record, we minimize what we store on our side to what the use case needs, and we honour revocation by tearing down the credential. The per-install identifier behaves, for us, as a long-lived API token: kept out of logs, scoped to one project, and rotatable by the user from inside the app whenever they want.

What we account for on this specific app

A few app-specific things shape the build. We handle them; they are not preconditions you have to clear.

First, the credential model. The recovery code the app gives the user is the only thing that ties one device to another and to the web log. We treat it as a sensitive secret on day one — never written to logs, never echoed in error traces, scoped to one integration, and rotated on demand. The same identifier is what the user can hand to a second device, so the integration has to behave reasonably when the same account is being read by two clients at once.

Second, the sync gap. The app works offline and brags about it; the cloud only ever lags the device. We surface a last-sync timestamp on every read so the calling code can decide what to do with stale windows instead of guessing, and we ship the report-parsing fallback so a long offline stretch does not silently vanish from your downstream view.

Third, the wire-capture step. The shapes the sync layer uses are confirmed under a consenting account we arrange with you during onboarding, then the client is built off that capture. The contract tests that ship with the build catch the case where ExpenseCount changes the wire format under us, so the failure mode is a red CI run, not a quiet drift in your downstream numbers.

Fourth, the family and mess case. The wider ExpenseCount product has a multi-contributor mode. If your users are in that mode, we scope the client to carry a participant field on every entry from the start, because retrofitting attribution later is more painful than designing for it on day one.

What ships at the end

For a typical MyXpense project the deliverable is small and well-bounded, because the underlying surface is small. You receive:

• An OpenAPI / Swagger spec covering the endpoints we identify — the device-token handshake, the log query, the category lookup, the report retrieval.
• A short protocol and auth-flow report describing the device-token model and how rotation and revocation work in practice.
• Runnable source in Python or Node.js — fetch_log, fetch_categories, parse_report — with the choice of language driven by your own stack.
• Contract tests plus a small fixture set of recorded responses with PII removed, so a future change at ExpenseCount surfaces in CI before it surfaces in production.
• A plain-English interface document you can hand to a non-engineer.
• Compliance and retention notes: consent capture, credential rotation, data minimization on our side.

Wire view

The shape below is illustrative — the actual endpoints, headers, and field names are confirmed during the build against a consenting account. It is here to show what the integration code looks like, not to claim a documented API surface.

POST /api/v1/log/query  HTTP/1.1
Host: expensecount.com
Accept: application/json
Authorization: Device <per-install-identifier>

{
  "since": "2026-04-01T00:00:00Z",
  "include": ["income", "expense"],
  "page_size": 200
}

-- 200 OK --
{
  "account": "8f3...",
  "last_sync": "2026-05-29T08:14:11Z",
  "entries": [
    {
      "id": "e_2026_05_28_001",
      "kind": "expense",
      "amount": 12.40,
      "currency": "USD",
      "category": "Groceries",
      "occurred_on": "2026-05-28",
      "note": "Sunday market",
      "participant": null
    }
  ],
  "next_cursor": null
}

The category endpoint is one shape simpler than this, and the report endpoint returns binary PDF that we hand to a parser inside the same client.

Sync lag, stated plainly

The sync that backs the integration is best-effort, not real-time. If a user has spent the morning entering expenses with the phone in airplane mode, those rows do not appear in our pull until the device next reaches the network. We expose the gap directly: every read carries the account's last-sync timestamp, so the calling code can choose to wait, to fall back to the report parser, or to mark the period as pending instead of silently presenting an incomplete window as complete.

Pricing, plainly

For MyXpense the build is small — a credential handshake, a log query, a category lookup, the report parser — so it sits at the floor of our scale. Source code, runnable and documented, is $300 and is not paid until you have taken delivery and confirmed it runs against your own account. You can skip the source step entirely and call our hosted endpoints instead, paying per call with nothing up front. The cycle is one to two weeks from sign-off; send the requirement details through the contact page and we will size it precisely.

Interface evidence

Screenshots from the Play Store listing. Tap to enlarge.

What was checked, and by whom

This page draws on the MyXpense entries on the Google Play Store and the US App Store, together with the publisher's own ExpenseCount product page and the mobile-apps section that describes the family-expense flow. The protocol capture itself is a build-time step we run under the engagement once a consenting account is in place; it is not done in this preview.

Mapped by the OpenBanking Studio integration desk · reviewed May 2026.

Other trackers in this shape

Apps an integrator who is sizing MyXpense usually compares against. The names are listed for context only — none is being recommended or criticized here, and the data shape across the set is broadly similar (line-item log, categories, time-period rollups), which is what makes a single unified integration practical when more than one is in scope.

• YNAB (You Need A Budget) — envelope-style budgeting with bank links and a categorized line-item log; the data shape is the same shape MyXpense produces.
• PocketGuard — leans on the "what is safe to spend" question, backed by a categorized transaction history.
• Monarch Money — household budgeting with categories, accounts, and a transactions log.
• Goodbudget — cross-device manual envelope budgeting; another no-bank-link, manual-entry app, closest in spirit to MyXpense.
• EveryDollar — Ramsey Solutions' line-item budget app; same kind of categorized log behind it.
• Spendee — manual plus connected wallets with shared budgets, popular for family use.
• Honeydue — couples-focused expense tracking; closer to the family-budget side of ExpenseCount.
• Simplifi by Quicken — manual entries plus linked accounts on a category-driven log.

Questions integrators of MyXpense ask

Mapping last checked 2026-05-29.