Mapping WeXpense's no-login group ledger for integration

Every WeXpense group lives behind a short share URL — the demo groups on expensecount.com look like expensecount.com/6pbPNva1 — with no username and no password between the link and the data. That single design choice decides the whole integration. There is no account to authenticate against; the link itself is the capability, and the same ledger is rendered by the Android app, the iOS app, and the desktop web client. An integrator's job here is to read a consenting group's ledger the way the web client does, normalize it, and keep it in sync as participants keep adding rows.

Where the numbers live

WeXpense keeps a compact but real dataset per group: who is in the group, every expense someone paid, how each expense is split, and the settle-up result the app computes to minimize the number of transfers. The website holds the full log history; the apps cache a working window and can record offline, then sync later. The table below maps each domain to where it originates and what an integrator does with it.

Getting at the ledger

Two routes genuinely apply to this app, and they are close cousins because the data is one shared ledger.

1. Protocol analysis of the share-link sync (recommended)

The web client at expensecount.com fetches a group by its share slug and renders the ledger; the apps do the same against the sync channel (the privacy policy names Firebase among the tools in use). We observe that exchange under the group owner's authorization, document the request, the response shape, and the sync behaviour, then build a client that reproduces it. Reachable: the full group ledger, splits, settle-up output, and the web log history. Effort is moderate. Durability is good as long as a re-validation step rides along with maintenance, since a front-end change can move fields. Access is arranged with you during onboarding by running against a group you control or a sample group you consent to share.

2. User-consented link access as the credential

Because the share URL is the capability, the cleanest consent artefact is the group owner sharing that link with the integration the same way they would add a participant. We treat the link as a bearer credential: scoped to one group, logged on use, and revocable by the owner regenerating it. This route pairs with route 1 rather than replacing it — it is how route 1 is authorized.

We would build on route 1 with the link-as-credential model from route 2 as its consent basis. There is no native data-export file documented for WeXpense, so a connector that reads the web ledger is the durable path rather than a one-off dump.

The sync call up close

Illustrative only — the exact path, headers, and field names are confirmed during the build against a consenting group, not asserted here. It shows the shape the connector targets: a group fetched by its share slug, then normalized.

GET https://expensecount.com/<shareSlug>        # e.g. shareSlug = "6pbPNva1"
Accept: application/json
# No auth header: the slug itself is the capability (bearer-style).

# Illustrative normalized response after the connector reshapes the raw payload:
{
  "group":   { "id": "6pbPNva1", "name": "Lisbon trip", "currency": "EUR" },
  "members": [ { "id": "m1", "name": "Ana" }, { "id": "m2", "name": "Bea" } ],
  "expenses": [
    { "id": "e1", "payer": "m1", "amount": 84.00, "currency": "EUR",
      "note": "Uber", "date": "2026-04-11",
      "splits": [ { "member": "m1", "share": 42.00 },
                  { "member": "m2", "share": 42.00 } ] }
  ],
  "settle_up": [ { "from": "m2", "to": "m1", "amount": 42.00 } ]
}

# Handling we wire in:
#  - slug rotated / 404  -> request a refreshed link, resume from last cursor
#  - offline-staged rows -> dedupe by (payer,amount,date,note) + server id
#  - mixed currency      -> keep per-item currency; never coerce to group ccy
#  - settle_up           -> re-derive from expenses+splits, do not trust cache

What lands in your repo

Each deliverable is tied to the surfaces above, not a generic checklist.

• OpenAPI specification for the normalized endpoints — group fetch, expense list, per-participant balances, settle-up transfer list.
• Protocol and sync-flow report: the share-slug fetch, the Firebase-style sync behaviour as observed, the offline-then-sync reconcile path, and how link rotation is detected.
• Runnable client source in Python and Node.js: pull a group by slug, normalize expenses and splits, re-derive net balances, emit the minimal transfer list.
• Automated tests against a consenting sample group, including a mixed-currency case and a delayed-sync dedupe case.
• Interface documentation mapping every field we expose back to where it shows up in the app and on expensecount.com.
• PIPEDA-aligned guidance on retention, minimization, and the owner-revocation path.

What we plan around

Three things about WeXpense shape how we build, and we handle each of them as part of the work.

• Link rotation as a normal event. A share slug can be regenerated by the owner, which is also the revocation mechanism. We design the connector with a re-fetch path so a refreshed link is swapped in and the sync resumes from the last reconciled cursor, instead of treating a rotated link as a failure.
• Offline-then-sync ordering. WeXpense records offline and syncs when a connection returns, so rows can arrive out of order and late. We make ingest idempotent and key dedupe on a stable tuple plus the server id so a delayed sync does not double-count an Uber fare.
• Web is the source of history depth. The website carries the full log while a phone caches a window, so we anchor the sync on the expensecount.com ledger and treat any device as a partial mirror — that keeps history consistent regardless of which participant synced last.

Access to a consenting group is arranged with you during onboarding; the build runs against a group you control or a sample group you choose to share.

Consent and Canadian law

ExpenseCount Inc. gives a Toronto contact address in its privacy policy, which puts this data under Canada's Personal Information Protection and Electronic Documents Act (PIPEDA), overseen by the Office of the Privacy Commissioner of Canada. PIPEDA's fair-information principles that bear directly on this work are consent, limiting collection to what the purpose needs, and an individual's right to access the personal information an organization holds about them. The published policy states data is shared only with participants the user explicitly shared a group with, and with law enforcement when legally required, and that Google Analytics and Firebase are used for analytics — all useful context when we scope what the connector reads. Our posture is consistent: access is user-consented through the group owner, reads are logged, the dataset pulled is minimized to the group in question, and an NDA is in place where the engagement needs one. Settle-up amounts and participant names are personal financial information, so the connector is scoped to a single authorized group rather than crawling slugs.

Where teams plug it in

• Travel and events ops: pull a trip group's net balances to trigger reimbursements once the group closes out.
• Bookkeeping sync: import expense items as line items into an accounting ledger, currency preserved.
• Shared-house or team dashboard: aggregate several WeXpense groups into one running view of who owes whom.
• Settlement automation: feed the minimal-transfer list into a payments rail so "settle up" becomes one action.

App screens

Screenshots from the store listing, useful for matching ledger fields to what users see. Tap to enlarge.

Other splitters in the same orbit

Same category, named so this brief widens to the wider expense-splitting space. Plain ecosystem context, no ranking.

• Splitwise — keeps group balances and an IOU ledger behind accounts; the most common target for a unified splitting view.
• Tricount — no-signup shareable group expenses, structurally close to WeXpense's link model.
• Settle Up — supports uneven, percentage, and itemized splits; richer split metadata to normalize.
• Splid — offline-first travel expense tracking that syncs later, similar reconcile concerns.
• Splitser — focused group split-and-settle with a clean shared group model.
• Cino — splits at point of payment via shared virtual cards linked to bank cards.
• SplitterUp — receipt scanning plus settlement optimization, a newer entrant.
• Spliit — open-source Splitwise alternative, self-hostable group expenses.
• Expensify — broader expense and reimbursement platform with a split feature.

Sources and review

Checked in May 2026 against the live web client, the developer's published privacy policy, and the Canadian regulator's PIPEDA page. Figures such as install counts, ratings, and the last update date come from third-party listings and are treated as approximate, not asserted here as exact. Primary sources opened: expensecount.com, the ExpenseCount privacy policy, the OPC PIPEDA page, and the App Store listing (formerly Group Xpense - track & split).

OpenBanking Studio · integration desk notes, May 2026.

Integrator questions

With no username or password, what authorizes access to a WeXpense group?

The share URL is the capability. A group is reachable by whoever holds its link, so the access we build on is the consenting group owner handing us that link, the same way they would add a participant. We treat the link as a bearer credential, log its use, and scope the connector to the single group you authorize.

Does the expensecount.com website hold more than the mobile app does?

Yes. The app caches a working window and can log offline, while the website carries the full log history for a group. We anchor the connector on the expensecount.com side so history depth is consistent and a phone that has not synced recently does not shorten what you ingest.

How do you handle a trip group with mixed currencies and the settle-up math?

We re-derive net balances from the raw expense items and split allocations rather than trusting a cached transfer list, and we carry the per-item currency through normalization so a multi-currency trip reconciles instead of collapsing to one assumed currency.

What if a group's share link is regenerated part way through the build?

Link rotation is expected, not an edge case. The connector is built with a re-fetch path so a refreshed link is swapped in without re-architecting, and the sync resumes from the last reconciled state rather than re-importing the whole ledger.

Which privacy rules apply to this data, given the developer is in Canada?

ExpenseCount Inc. lists a Toronto contact address in its privacy policy, so Canada's Personal Information Protection and Electronic Documents Act (PIPEDA), overseen by the Office of the Privacy Commissioner of Canada, is the working frame: consent, limited collection, and an individual-access right. We build for data minimization and keep consent and access records.

Bringing WeXpense data into your stack

A WeXpense connector — group fetch by share slug, normalized expenses and splits, re-derived balances, and the link-rotation re-fetch path — typically ships in one to two weeks. Source-code delivery starts at $300, billed only after the code is in your repository and you have confirmed it runs the way the documentation says; if you would rather not host anything, call our hosted endpoints instead and pay per call with nothing upfront. Tell us the group you want to read and what you need out of it, and we will scope it — start at /contact.html.